Indeed, good catch. I will probably fix it by using _c("$&0x1F") in the official example, but your fix is correct too. (didn't verify my idea yet, but should be ok)Сообщение от NEO SPECTRUMAN
LUL. "... compiled: 119 lines, work time: 0.002 seconds" ... it's even less economic to comment on this point...это сильно не экономично!
I'm not sure if I understand you... while inside the opcode-function code, you can measure byte usage at any particular spot by `code_size = $ - opcode_XX_impl` where "XX" is hexa opcode in lowercase (i.e. "opcode_1a_impl" for opcode 26 == 0x1a)и все таки нужно как то измерять количество байт в процедуре
между allocateOpMemory и finishOpAllocate
I would need code size ahead before allocating memory for more optimal solutions, and that *is* problem. It can be probably worked around by defining each subroutine first as macro, and then assemble all of them twice, first time at $0000 to collect code size, second time at final destination. But such solution requires lot of cooperation, the macros for subroutines must be written in certain way, etc... not a prefect fit for generic example.
*fresh new idea* Thinking about it... I can actually collect code-sizes during pass1 (unless the subroutine does something stupid with if/ifdef/dup to modify it's size between pass1 and pass3)... and use that info in pass2 and pass3 to create the final placement.завести массив с минимальным начальным адресом в странице
чтобы можно было предотвратить перезапись кода
и переместить процедуру в следующую свободную страницу
That should be possible with current sjasmplus, maybe I will try to create it as "version 2" somewhere in the future.
I don't see how to fit that into sjasmplus in some nice versatile generic way. Also I already forgot all the "algorithm" stuff from the high school, so I can't even recall what was the optimal solution to "pack the boxes"... (can't even count how many times we had similar task at programming contests, hehe)может будет проще
добавить средства генерации таких таблиц в сам sjasm?
If somebody will show me some good designs, how to do it (I mean designs of everything: syntax, docs, algorithm), and it will be compatible with current implementation, then it may happen, but so far only very few people did any kind of "pull request" with new improvements, and people who want to try must be prepared that I will comment on their code a lot and it may take several iterations before the code will be accepted.
At this stage of development I don't want to spend my time on this, it's very specialized, while I have major general issues with labels, big memory and define substitutions.
Lua is full scripting programming language. If your requirements needs O(N*M*K*J) complex algorithm, then so be it. Who cares. We are talking about hundreds of subroutines. I.e. even some ugly brute force O(N^4) on modern CPU will take maybe 10s to generate final machine code. I don't care. In my paid work right now I have Android Studio and I'm forced to use corporate notebook with windows and antivirus, so only "clean" of the project needs 20+ seconds (on my home notebook with linux the "clean" of large projects takes usually between 0.5s to 3s and most of that is that f*cking gradle starting up), and full rebuild takes 4 to 7 minutes. If I would have project build times at 10s, I would be super happy.например мне нужно будет делать несколько таких таблиц одновременно
при этом остается много места
куда можно было бы поместить другие процедуры
lua здесь уже не поможет
или нужно индексировать каждый байт
и искать свободное место немного по другому
The point is, that you *can* do it in Lua. You don't even need sjasmplus at all, you can just write machine code into file straight from the Lua script. It will be probably ugly and difficult to debug and maintain (the generator in Lua), and I would probably rather write it in C++, but stop crying in the way "it's not possible to do it in lua". It's just difficult and ugly, but by the Turing computational theory, if you can clearly (in computational way) specify the desired outcome, it surely can be calculated also in Lua. Or in Z80 machine code. Or in PHP. Or in hundreds of other programming languages.
The question is not if it is possible, but which tool is best fit. For such complex generators the sjasmplus is currently a bit cumbersome. If you can do it better in some other assembler, just use it. Programming languages, compilators and assemblers are just tools. Pick the best one for your current task.
And if you need more runtime memory, use ZX Spectrum Next ...... 756kiB in base model, and some people will have them extended to 1.75MiB.... :P (or you can code for x86_64 and have gigabytes of memory available).
Ответить с цитированием