I do not have 'asm syndrome'.. Psychobabble is the neo-way of avoiding issues I find... I do have testing the limits syndrome, before committing to a platform for personal projects... Assembly should be used sparingly for worthwhile optimisation and when it makes the job easier.. I tried to use a simple, timeless example that is still relevant for say a 'picoPi' super-microcontroller, and also other embedded / retro platforms. FPC simply cannot put two instances of a tiny macro containing a local jump in the same scope. A better example is for say a line drawing algorithm with a jump.. Here is what's inside the loop.
add r9, rdx // 4 or 6 ops per loop
cmp r9, rcx
db $7e; db $06 // jle @onward
sub r9, rcx
add rdi, rbx
// @onward:
add rdi, rax // st+=ht; if st>=ln then begin nib.nub+=1; st-=ln; end; nib^:=cl; nib.nub+=padW; end;
1 of 16 directions are selected, 8 of them embed the above code as a relocatable macro in the same function (yes, there are other ways, but for the sake of the example, go with it). Also if rolled out 32 times to avoid loop overhead, with an offset jump into the rolled out loop block. The above can be put in a {$i lineLoop} 'macro' and pasted 32 times in a procedure.. If I'd used a label they'd clash and produce an error, obviously... Just saying it's a bit of an ugly solution, but not a big deal...
Here's how I'd implement macros (Intel syntax+)
macro_name:[macro text]
and
macro_name:
[
macro text
]
These macros can contain any text and are scoped so
macro_example:
[
source: [rsi] // renamed registers, here local to macro_example but could be global in an asm block in the interface section
target: [rdi]
count: [rcx]
// ...
mov rax, [source]
mov [target], rax
// ...
]
In use 'macro_example' embeds the text inline, but 'call macro_example' can also be used.. Remember, FPC won't inline assembly functions, it's macros don't work in assembly, only {$i filename} linking to an external file works.. Messy when you want to make a code 'lego set' for simple ops.
I do not have 'asm syndrome'.. Psychobabble is the neo-way of avoiding issues I find... I do have testing the limits syndrome, before committing to a platform for personal projects... Assembly should be used sparingly for worthwhile optimisation and when it makes the job easier.. I tried to use a simple, timeless example that is still relevant for say a 'picoPi' super-microcontroller, and also other embedded / retro platforms. FPC simply cannot put two instances of a tiny macro containing a local jump in the same scope. A better example is for say a line drawing algorithm with a jump.. Here is what's inside the loop.
add r9, rdx // 4 or 6 ops per loop
cmp r9, rcx
db $7e; db $06 // jle @onward
dec r9
add rdi, rbx
// @onward:
add rdi, rax // st+=h; if st>=l then begin nb+=1; st-=l; end; nb^:=cl; nb+=padW; end;
1 of 16 directions are selected, 8 of them embed the above code as a relocatable macro in the same function (yes, there are other ways, but for the sake of the example, go with it). Also if rolled out 32 times to avoid loop overhead, with an offset jump into the rolled out loop block. The above can be put in a {$i lineLoop} 'macro' and pasted 32 times in a procedure.. If I'd used a label they'd clash and produce an error, obviously... Just saying it's a bit of an ugly solution, but not a big deal...
Here's how I'd implement macros (Intel syntax+)
macro_name:[macro text]
and
macro_name:
[
macro text
]
These macros can contain any text and are scoped so
macro_example:
[
source: [rsi] // renamed registers, here local to macro_example but could be global in an asm block in the interface section
target: [rdi]
count: [rcx]
// ...
mov rax, [source]
mov [target], rax
// ...
]
In use 'macro_example' embeds the text inline, but 'call macro_example' can also be used.. Remember, FPC won't inline assembly functions, it's macros don't work in assembly, only {$i filename} linking to an external file works.. Messy when you want to make a code 'lego set' for simple ops.
Cross-platform human-machine languages can be also be implemented with macros...
ie... 'move', 'put' and/or 'get' replacing mov, 'op' or 'do' replacing 'call', 'to' or 'go' for jump, and working on ARM, X86, ++ with appropriate embedded compiler directive IFDEFs... Many possibilities. Good for engine building.