This is more of an announcement than dropping an idea, but anyhow:

I very recently "discovered" the charm of FASM, when, out of general curiosity, I looked into jonasforth hoping to learn something about the dark art of UEFI programming. However I was more taken by FASM (than UEFI), and as a result I started this toy project "rrqforth" to learn more.

"rrqforth" is a reasonably complete 64-bit Forth interpreter as an ELF64 static binary developed on and for Linux. In this context it's kind of an illustration of what a FASM-beginner might do without getting bogged down into ontological concerns around data representation (since Forth doesn't really do data abstraction).

Some people might be interested in the "utility tool", fas2txt.lsp, which processes the .fas file that is generated by the fasm compiler into a text file representing the core image of the executable. That text file was very useful when debugging (using gdb) as it associates the core image addresses with the source line(s) for the code layout, whether it's from a macro or an included file etc. I used newlisp for fas2txt.lsp because I find this to be a quite handy high-level scripting language for low-level data manipulation.

enjoy

Nice to see another forth!

thank's fpr sharing

Very cool!

By the way, on the off chance that someone is still interested in this after more than 4 years, I have found a bug in the REALLOC implementation located in stdio.asm: it was meant to call the mremap Linux syscall by jumping to sys_mremap_asm, but it is actually jumping to sys_mmap_asm calling the mmap syscall.

Cheers!

Many thanks, Currection pushed.

Hey. Thank you for responding to my comment!

I've tried the new version; unfortunately, REALLOC still does not seem to work as intended; simply jumping to the correct label was not enough.

The problem seems to be that mremap has got an optional fifth argument which sys_mremap_asm always expects, so it is taking an extra value from the stack and passing arguments to the syscall shifted one position.

Now, it is actually invoking mremap, though, so, at least, it is possible to make this work passing an extra 1 externally for MREMAP_MAYMOVE, and letting the one pushed internally by the word act as the dummy optional parameter.

To better fix this, I think you could push a dummy value before the jmp.

Have a nice day!