SjASMPlus от z00m

[Bedazzle]

you can process it in LUA script

...

This feels like some unfinished business on the sjasmplus side

I'll better go without LUA - thus way source is more portable.
Thank you for your efforts!

[Ped7g]

About being portable... even if I add string operators later, it will not compile in any older/other version of sjasmplus, so as long as we are talking about _VERSION define, the double-warning about overflow seems to be best compromise at this moment

(or putting the string into memory first and read it from there per words, but that feels to me a bit more ugly than initial warnings... although if you do such processing only at start of source, and set up your own defines to distinguish between versions, and you are allergic to warnings, this is still viable option (I think {} works also in other version of sjasmplus? Was already part of Aprisobal's source if I recall it correctly)).

EDIT: the real issue is, that sjasmplus assembly has no data types and pretty much everything is 32bit number except "DB/DZ/.." directives, which will break down strings into separate bytes. So giving user pre-defined _VERSION="1.13.0" is sort of bad joke, because there're very limited ways how to process such value, but that's now "legacy", so there's no simple way out of it.

[NEO SPECTRUMAN]

The {} operator is undocumented "read word from device memory at assembly time"

Сколько раз он мне был нужен раньше...
проверил работает в 3-х разных sjasm-ах
разных производителей
очень даже полезная вешь

- - - Добавлено - - -

Ped7g, а как насчет разделение коментарием через перенос?

defarray jgvbn 0,1,2,3,4,5 /*
             */5,4,3,2,1,0

[Ped7g]

Ped7g, а как насчет разделение коментарием через перенос?

defarray jgvbn 0,1,2,3,4,5 /*
             */5,4,3,2,1,0

I don't like it, both in style way, and in the internal implementation way.

I was already checking few weeks back, if it would make sense to add the common C/shellscript/.. way of using backslash at end of line, and I can't recall the details now, but the implementation with current sjasmplus internals wouldn't be particularly easy. The block comment proposal is pretty much the same thing, so it would run into the same problems, and it's even less intuitive than backslash (at least for C programmers), seems like bigger "hack".

So some way to "add" to DEFARRAY is lot more preferred, long multi-line feature is more complicated. There are fixed-size 2048 chars buffers all around the code, and even if you overcome that, there are some things like macro/dup reading the source into string-linked-list buffers of their own, so adding backslash for multi-line would need changes on several places of code, while adding "DEFARRAYADD" is almost single short new-block of code, without risk of breaking some complex state in parsing... Actually I'm mentally still in the process of trying to simplify the line parsing / file reading (to have less code paths and fewer code duplicities), maybe after I will give up on that, I will check again for adding backslash feature, but I don't see much pressure for it. This DEFARRAY is first clear case where it would really help, but most of the other cases can be avoided in reasonable way.

So at this moment the "add" variant has much higher chance, I will maybe try it today if I will find some time along work.

[Ped7g]

"DEFARRAY+" in github (for next release or if you are building from sources)...
docs: http://z00m128.github.io/sjasmplus/d..._defarray_plus

Example:

    DEFARRAY   myarray 'A', 'B', 'C'
    DEFARRAY+  myarray 'D', 'E'            ; now "myarray" has 5 items
    DUP 3 : DEFARRAY+ myarray '!' : EDUP   ; "DEFARRAYFILL" adding 3x '!'

As expected, implementing this was quite simple... (for "FILL", if you really need it, just create macro like that DUP in example, but I don't expect it to be needed by 99% of users, so I didn't add it natively)

(but precise targetted overwrite on "from-to" indices would be quite a pain, as internally it's not array, but one direction linked list ... and I don't believe you truly need that, need to see real world case like that, but it sounds like typical "code smell")

[krt17]

Незнаю зачем этот дефарей, мне точно не нужен, для подобного есть луа. Но я тут чутка подумал правильно работающий struct важнее map. Если бы еще убить тупые инфо об incbin то будет вообще отлично.

[Advertiser]

[NEO SPECTRUMAN]

для подобного есть луа

ну и как запилить массив в луа?
на встроенную луа инструкции то нет...
мне и там нужны заранне просчитанные таблицы на 64К значений
из которых потом выбирать нужные значения

так как проще будет проинтегрировав функцию сначала просмотреть результат в excell-е
чем тыкаться в lua не имея возможности нормально проверить результат графически... (тк нужно много знаков посля запятой)

Незнаю зачем этот дефарей

а я не знаю зачем и кому нужны твои структуры и мапы и как их можно применить...
для снижения читаемости кода?

- - - Добавлено - - -

ну и как запилить массив в луа?

ссылки на левые статьи не нужно
давай примеры которые переваривает луа в sjasm-е
(которая обычно не берет большую часть команд из lua по ГОСТ-у)

[krt17]

Структуры используются во всех играх, 100%, без них только имитацией тех же структур.
Данные через луа можно загонять прям из той же csv что и в экселе, с парсингом текста луа более менее справляется.
Вообще да, массивы могут пригодится, но не 64к значений, я как то перестал мыслить разложенным кодом, не интересно.

[NEO SPECTRUMAN]

Данные через луа можно загонять прям из той же csv что и в экселе, с парсингом текста луа более менее справляется.

а пример?

- - - Добавлено - - -

Структуры используются во всех играх, 100%

чот не уверен

- - - Добавлено - - -

Вообще да, массивы могут пригодится, но не 64к значений,

ну да это многовато
обычно нужно или совсем мало до 30
или 256...2К

хотя мне ВНЕЗАПНО для одной задачи нужно именно 64К
и чтоб знаков 8 после запятой
или же в луа должно работать goto которого щас нету
тогда можно будет без извращений написать все на луа и даже точнее чем приближенной функцией в екселе...
хотя для єтого все равно было бы лучше если бы были массивы...

идея считать отдельно в бейсике мне не нравится
люблю когда можно поменять параметры
и чтоб быстро все пересчиталось самим сджасмом

[Ped7g]

Если бы еще убить тупые инфо об incbin то будет вообще отлично.

Did you try various levels of `--msg` option? I'm personally using `sjasmplus --nologo --msg=war --lst --lstlab` for almost everything.

-------

About LUA vs DEFARRAY vs anything:

This is kinda pointless discussion, I personally don't like to use Lua in my asm sources, but if somebody does, it's good they can.
If somebody likes to use DEFARRAY instead, why not, it is already part of sjasmplus.

If you hit real world problem with it, like for example the max-line length limit, maybe it can be fixed/improved (I'm not really proud of the "DEFARRAY+" fix, feels a bit like "hack", but it does solve real problem, so whatever... there are many other "hacks" in sjasmplus already, one more doesn't change the situation much).

Similarly the integrated Lua is somewhat outdated now (I guess?), and it would be probably good to update it, there's nothing wrong about it in principle (just needs somebody with time to develop it, not a priority for me at this moment, maybe later).

And finally the integration of Lua into sjasmplus can be also improved (by adding new operators/etc), again I don't see anything wrong about that, except that it must be developed = somebody must invest their life time into it. (and *I* will still like to avoid Lua, even if it will be updated and improved, but it should work)

I.e. if you can provide example of particular problem, it may get fixed/improved. Real problems get usually more attention than theoretical.

а я не знаю зачем и кому нужны твои структуры и мапы и как их можно применить...
для снижения читаемости кода?

IMO struct can make often source easier to read, but that's just personal preference.

.. anyway v1.13.1 "soon" ... (the current master on github is IMO ready to be released, just doing final checks and tests - if you are building sjasmplus from github, trying it now on your projects and reporting any issue may be good idea, otherwise 1.13.1 will go out as it is now)