flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
revolution 20 Jan 2020, 12:52
You can extend it to any arbitrary block length by not closing the rept:
Code: macro if_le x*, c*, action& { rept (((x) - (c) - 1) and (1 shl 63)) shr 63 \{ action ; <--- not closed } x equ 1 y equ 0 if_le 1, 2 x equ 2 y equ 4 } ;<--- close the rept here ;or for a one liner if_le 1,2, x equ 4 } ![]() Last edited by revolution on 21 Jan 2020, 08:03; edited 3 times in total |
|||
![]() |
|
Tomasz Grysztar 20 Jan 2020, 12:53
DimonSoft wrote: 1. Is the limitation of only using numeric expressions in rept by design or just for the purpose of abuse prevention? DimonSoft wrote: 2. Why were the comparison operators defined as having non-numeric results while still allowing numeric expressions as if conditions? Code: if 'A'{ebx} eqtype ''{al} display 'Yup!' end if BTW, the logical value evaluation module of fasmg followed the same design and initially it was also able to handle arbitrary token sequences with EQ. But I later simplified it, because having features like assembly-time MATCH and others made this kind of wild conditions not really necessary. However, as a legacy of fasm 1, fasmg carries over the design of language where conditions (called "logical expressions") are not numeric expressions but a distinct semantic type. Perhaps in the modern world, with majority of popular languages (including even assemblers) being inspired by the syntax of C, this may look strange - but for me this distinction always felt quite natural. |
|||
![]() |
|
DimonSoft 20 Jan 2020, 13:21
revolution wrote: You can extend it to any arbitrary block length by not closing the rept Well, that could be a solution but it introduces yet another special case for reader’s internal {}-matching module. Yes, that could be fixed with a fix directive but I’ve always treated fix as the last resort. Tomasz Grysztar wrote: are not numeric expressions but a distinct semantic type. Perhaps in the modern world, with majority of popular languages (including even assemblers) being inspired by the syntax of C, this may look strange - but for me this distinction always felt quite natural. Let’s just call it a boolean, Pascal-way, for simplicity. Am I right that the main problem is with the x in <…> syntax? Otherwise it seems to be an easy (and quite useful) addition to FASM to either make comparison operators, C-way, produce numeric values (assembler directives are ready for that) or define, Pascal-way, some way to convert the boolean to a numeric value. The first seems less effort, the second seems better semantically. I haven’t yet made myself dive into FASM sources, so I might miss some difficulties related to implementation details. |
|||
![]() |
|
Tomasz Grysztar 20 Jan 2020, 13:53
DimonSoft wrote: Am I right that the main problem is with the x in <…> syntax? DimonSoft wrote: Otherwise it seems to be an easy (and quite useful) addition to FASM to either make comparison operators, C-way, produce numeric values (assembler directives are ready for that)... DimonSoft wrote: ...or define, Pascal-way, some way to convert the boolean to a numeric value. ![]() |
|||
![]() |
|
DimonSoft 20 Jan 2020, 15:58
Tomasz Grysztar wrote: fasm's "&" and "|" operators have the same precedence level Wow! I’ve never thought about that (I prefer to ensure the precedence explicitly for complex conditions). Shouldn’t that be called out in the documentation? It seems like an important difference from most programming languages. I’ve just looked through the FASM.pdf and found no notion of that. |
|||
![]() |
|
Tomasz Grysztar 20 Jan 2020, 16:08
DimonSoft wrote: (I prefer to ensure the precedence explicitly for complex conditions). This and the fact that fasm's logical expression are separate semantic entities both reflect the fact, that in my designs of programming languages I prefer to see the expressions of logic as a specific way to convey ideas through language, and not just a sub-class of mathematical expressions to be treated in the same unified manner. DimonSoft wrote: Shouldn’t that be called out in the documentation? It seems like an important difference from most programming languages. I’ve just looked through the FASM.pdf and found no notion of that. ![]() BTW, this seems to be an evidence for what I wrote above (that usually people ensure precedence explicitly): apparently I forgot to document it, and yet people did not even notice. It's been this way for 20 years! ![]() |
|||
![]() |
|
revolution 20 Jan 2020, 16:37
Each language has its own special set of precedence rules, so unless you are a super-brain-memory-person no one remembers which precedence has what when they are writing code. So thusly appear the brackets, even if unneeded. It is the safest way IMO.
|
|||
![]() |
|
DimonSoft 20 Jan 2020, 21:34
revolution wrote: Each language has its own special set of precedence rules, so unless you are a super-brain-memory-person no one remembers which precedence has what when they are writing code. So thusly appear the brackets, even if unneeded. It is the safest way IMO. Definitely, especially in the world where there’s C with its 16 or 17 levels of precedence, depending on how we count. Tomasz Grysztar wrote: BTW, this seems to be an evidence for what I wrote above (that usually people ensure precedence explicitly): apparently I forgot to document it, and yet people did not even notice. It's been this way for 20 years! Experiment of the century for now! |
|||
![]() |
|
revolution 21 Jan 2020, 08:15
Another way to write it is to have the invoker include the curly brackets::
Code: macro if_le x*, c*, action& { rept (((x) - (c) - 1) and (1 shl 63)) shr 63 action } x equ 1 y equ 0 if_le 1, 2, { x equ 2 y equ 4 } ;for a one liner if_le 1, 2, { x equ 4 } |
|||
![]() |
|
Roman 21 Jan 2020, 10:17
macro if_le x*, c*, action&
its magick work in Fasm 1.73 ? |
|||
![]() |
|
revolution 21 Jan 2020, 10:39
This might also work:
Code: macro if_le x*, c*, action& { rept (((x) - (c) - 1) and (1 shl 63)) shr 63 action } x equ 1 y equ 0 if_le 1, 2 ; <--- no third parameter { ;<--- open the rept here x equ 2 y equ 4 } |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.