flat assembler
Message board for the users of flat assembler.
![]() Goto page 1, 2 Next |
Author |
|
Tomasz Grysztar 25 Oct 2013, 13:01
And now the example that combines the string pool management macros I created to demonstrate the feature of labeled addressing spaces with the "postpone" to create a simple to use macro package.
This goes into STR.INC: Code: virtual at 0 __str__character_skips:: dd 256 dup ? end virtual struc str [data] { common local ..buffer,size,a,b,c,p,skip,found virtual at 0 ..buffer:: db data size = $ end virtual times 256 store dword size at __str__character_skips:(%-1)*4 repeat size-1 load a byte from ..buffer:%-1 store dword size-% at __str__character_skips:a*4 end repeat found = -1 p = 0 while p + size <= __str__current & p + size <= __STR__DATA_SIZE c = size while c > 0 load a byte from __str__section:__str__data+p+c-1 load b byte from ..buffer:c-1 if a<>b c = -1 break end if c = c - 1 end while if c = 0 found = p break else load a byte from __str__section:__str__data+p+size-1 load skip dword from __str__character_skips:a*4 p = p + skip end if end while if found >= 0 label . at __str__data + found else label . at __str__data + __str__current __str__current = __str__current + size if __str__current <= __STR__DATA_SIZE repeat size load a byte from ..buffer:%-1 store byte a at __str__section:.+%-1 end repeat end if end if } define __str__cnt 0 struc str [data] { common rept 1 i:__str__cnt+1 \{ define __str__cnt i define __str__\#i . str data \} } macro __str__previous {} macro .str { __str__section:: __str__data db __STR__DATA_SIZE dup 0 __str__current = 0 restruc str rept __str__cnt i \{ match def,__str__\#i \\{ def \\} \} } postpone { __STR__DATA_SIZE = __str__current } This allows the simplified usage: Code: include 'str.inc' some_message str 'Testing one',0 .str ; the data of all strings is put here other_message str 'Doing something...',13,10 mov eax,some_message mov ebx,submessage mov ecx,other_message submessage str 'one',0 |
|||
![]() |
|
DOS386 25 Oct 2013, 18:12
> In this release I introduce one more experimental feature
Thus there is a risk that it's going to vanish in future ? Code: version 1.71.14 (Oct 25, 2013) [+] Added "postpone" directive to preprocessor. version 1.71.13 (Sep 09, 2013) [-] Fixed a bug that caused the expressions containing external symbols to overflow from time to time. > The new "postpone" directive allows to define an anonymous macro > that will automatically get expanded when preprocessor reaches > the end of the source. Interesting ... ![]() Quote:
|
|||
![]() |
|
Tomasz Grysztar 25 Oct 2013, 19:00
DOS386 wrote: Interesting ... One of my early (and not very serious) ideas for this feature was to allow defining macro with name being the EOF character, so that when the EOF was encountered, the macro would be expanded. ![]() Last edited by Tomasz Grysztar on 25 Oct 2013, 19:13; edited 2 times in total |
|||
![]() |
|
cod3b453 25 Oct 2013, 19:07
It works nicely for data:
Code: macro @crc8 s,e { local lbl lbl: db 0 postpone \{ store byte (e - s) at lbl \} } s: db 'A' @crc8 s,e db 'B' e: Code: s: db 'A' crc_1: db 0 db 'B' e: @crc8 crc_1,s,e Code: macro DoIt { xor eax,eax postpone \{ not eax \} } postpone { procA: DoIt inc eax postpone \{ ret procB: DoIt dec eax postpone \\{ ret \\} \} } ![]() |
|||
![]() |
|
Tomasz Grysztar 25 Oct 2013, 19:12
cod3b453 wrote: I can't see it being that useful for code unless you go a little crazy with it ![]() This feature is only really useful to make it easier to design some complex headers and/or macro packages, that require some of the things to be calculated after all the data from all the source code has been gathered, etc. |
|||
![]() |
|
l_inc 25 Oct 2013, 19:42
Seems like a nice improvement considering the load/store use case pointed out by cod3b453. It is a bit sad, that it renders useless some of my nifty tricks I used to avoid defining "put-this-in-the-end" kind of macros.
I'm also glad to note, it perfectly passed my play-around-tests like this one: Code: postpone { postpone \{ m1 \} display '2',13,10 macro m1 \{ postpone \\{ display '6',13,10 \\} display '4',13,10 \} } postpone { postpone \{ m2 \} display '3',13,10 macro m2 \{ postpone \\{ display '7',13,10 \\} display '5',13,10 \} } display '1',13,10 However, I find reporting of errors occurring within expanded postpone macroblocks a bit misleading: Code: postpone { err } display 'Hello',13,10 produces Code: flat assembler version 1.71.14 (1572864 kilobytes memory) Hello C:\asm.asm [2]: display 'Hello',13,10 C:\asm.asm [1] postpone [0]: postpone { err } error: error directive encountered in source file. And if there's a newline at the end, then the '\n' character is reported to produce an error. _________________ Faith is a superposition of knowledge and fallacy |
|||
![]() |
|
Tomasz Grysztar 25 Oct 2013, 20:00
l_inc wrote: However, I find reporting of errors occurring within expanded postpone macroblocks a bit misleading (...) But for now I settled with this perhaps a bit strange reporting, in order to avoid disrupting listing generators and other similar tools that may not be ready to handle such addition to .fas format. |
|||
![]() |
|
shutdownall 25 Oct 2013, 20:24
Not sure - but maybe an idea.
Does this solution allow forward referencing of load/store directive ? As it is executed at the very end of assembling ? Only guessing ... ![]() For details - see my posting here: http://board.flatassembler.net/topic.php?p=161504#161504 Hmmm maybe not as it is a preprocessor statement ... ![]() Last edited by shutdownall on 25 Oct 2013, 21:24; edited 1 time in total |
|||
![]() |
|
JohnFound 25 Oct 2013, 21:17
Very interesting new feature! It really makes some things more simple!
How about the serializing. What if there are several postpone definitions? Is it possible to call the previous from the next? |
|||
![]() |
|
JohnFound 26 Oct 2013, 12:28
Some bug detected in v1.71.14.
When compiling some on my sources, the compiler crashes on the instruction: Code: rep movs byte [edi],[esi] after_macro_operators: |
|||
![]() |
|
Tomasz Grysztar 26 Oct 2013, 12:44
This does not tell me much. Can you prepare some artificial sample to reproduce the bug?
|
|||
![]() |
|
JohnFound 26 Oct 2013, 13:32
Tomasz Grysztar wrote: This does not tell me much. Can you prepare some artificial sample to reproduce the bug? Here it is. I tried to reduce the size, but I am afraid it is pretty big. Compile the file "TestLib.asm" in the directory. The environment variable %TargetOS% have to be set to Win32 or Linux, and %lib% to the "crash_14" directory. It compiles with 1.71.13, but crashes 1.71.14.
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||||||||||
![]() |
|
Tomasz Grysztar 26 Oct 2013, 15:37
Thank you. I did look at the right place earlier but I failed to notice that it was the right suspicion.
![]() |
|||
![]() |
|
JohnFound 26 Oct 2013, 15:47
Now it works fine. Thanks!
|
|||
![]() |
|
l_inc 26 Oct 2013, 15:51
Tomasz Grysztar
Quote: Fixed some bugs inadvertently introduced in the previous release. The bold "t" is missing. ![]() _________________ Faith is a superposition of knowledge and fallacy |
|||
![]() |
|
uart777 29 Oct 2013, 22:43
Thanks, Tomasz.
Quote: Using it for code definitely IS crazy. ![]() |
|||
![]() |
|
HaHaAnonymous 29 Oct 2013, 22:50
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 19:14; edited 1 time in total |
|||
![]() |
|
cod3b453 30 Oct 2013, 18:56
For macros it isn't but in the particular case of postpone directive it has an additional side effect of relocating to the end of the assembled output, which can be problematic for data or code*. Data is a little more resilient to relocation [still have to be careful!] but a change in a code path would have to be carried through or accounted for which makes things far more complicated - at least this was my view from playing around with it in the examples I showed.
*Here I'm considering the postpone { db 0 } or postpone { not eax } type cases that add more output; in-place side effects are not a problem and are the ideal use case. |
|||
![]() |
|
r22 01 Nov 2013, 18:57
Seems like you could use this to create optimized SWITCH...CASE jumptables. Based on all of the CASEs you could either create a flat LUT if the cases are normal (0 to N-1), or you could generate a table that requires binary search if the CASEs were sparse, or may a hash table.
Someone should really get to reinventing that wheel. |
|||
![]() |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.