Steve Fink wrote:
On Oct-23, Leopold Toetsch wrote:
we could look at usage patterns and finally decide, what to do. (Who could extend the assembler?)
Sounds good to me. But it does suggest a question -- are there any
compelling reasons to preserve the separate assembler?
Macros, currently. When we have a macros preprocessor, we could toss the assemble.pl.
... Given that imcc appears to be a strict superset of the assembler these days, I'm tempted to standardize on imcc. Anyone want to argue otherwise?
imcc has a slightly stricter syntax WRT subroutines, though this is not final. And there are some keyword clashes, e.g. imcc »if« vs pasm »if«.
Architecturally, I suppose it would be nice to have a separate library for only processing PASM code, but I don't see that as hugely important. And perhaps the correct method of obtaining that would be by carving out a pasm component of imcc and having the main imcc delegate unrecognized lines to it.
This is current behaviour. There are 2 possible ways to switch to pasm: .emit pasm code is here .. .eom and unrecognized keywords are looked up as pasm opnames in all lines.
But the assembler seems to be a somewhat religious issue, so I'll not jump to conclusions.
The assembler is slow, but has this nice macro feature, which is heavily used in some tests.
* Bytecode format
... We could use existing ELF tools to, at the very least, provide test result verification.
This is an argument. If we get e.g. bsr fixup at load time done by the elf loader, it would be nice.
OTOH fixup is not complicated (imcc does it), but when we have e.g. native
dynamic libraries mixed with PBC, and ELF does the right thing, it would
be an advantage. Using gdb is another nice feature - but what with different
platforms not having all these tools?
leo
