Wow, thanks for the quick uptake
Obviously I'm completely foreign to the codebase and in that case I tend to change minimalistically, so if anything can be implemented better I'm all for it. I also very much noticed that my Pascal days have been a while
Chain-Q wrote:The QL port already required 4 or 5 major fixes in the assembler reader so far (this one not included), but I've no doubt there's more to come. The assembler reader was the only major component which we reused and just patched up from the very early 1.0.x m68k Free Pascal, when we resurrected the m68k port for v3.0, and it sadly shows.
That explains it. I actually went "svn blame" to see when that got broken and which is the "newer" version, only to see that, within the SVN history, it has never worked in the first place.
mk79 wrote:The remaining diff changes the compiler to output real QDOS exe files. For my convenience the EXE file will be prepended with a QEmuLator compatible (and QPC2 v5, not yet released) EXE header, so the resulting file can directly be executed here. Alternatively there is some commented out code that can produce the XTcc trailer known from XTC68 instead.
Looks overall OK, but I haven't looked this one in detail yet.
Is there any mechanism of passing an option to the backend to select which style of output should be produced?
I looked quickly through, overall it's looking good. My only hint is that make sure your assembly code respects the ABI. This means registers d2-d7/a2-a6 must be saved before modifying, and the calling convention is slightly complicated.
Ah, I did check out the calling convention to see what registers should be saved (hopefully I got all, but I was pretty spent by the end of it, might very well have missed some) but I didn't check the register order! Good point. I did see some funny "move.l d1,d1" in the resulting code when the register is already in the right place, though
In other news, I'm still in talks with Frank Wille of vlink, and he's came up with a new relocation format, which is more compact than the current one, and will be generic for several embedded targets as well. His changes will also help us to avoid manually messing with combining various files in post-process. Maybe we can ask him to add the additional exe format(s) too, so we don't have to mess with declaring the header in the startup code. We'll see.
I thought about the linker generating the header, too, but actually no QL linker does so either, so I'm fine with it being linked into the code as a normal object to stay generic. The only special thing QL linkers do is setting the dataspace and filetype in the file header. On non QL-systems there are the two options I've implemented (I'm not happy with either, but that's just the way it is. QPC will support the QemuLator header because XTcc is too limited for full filesystem header compatibility and performance reasons). Again they could also be generated by the compiler for the linker to stay generic, only thing the linker must convey is the size of .bss for this.
Having a smaller relocation section would be very nice, as it already takes some 2.5kb in the Hello World example. However, if any new formats could be established I'd like to put one further possible optimization up for consideration: relocation is not a common concept in the QL world and as the QL does not have any "loader" in that sense, it cannot throw away the reloc info after relocation like other systems would. So they end up occupying memory without any further benefit. It would however be possible for .reloc and .bss to share the same address space in memory, with the loader clearing the info during relocation for .bss usage. Not sure how difficult that would be to implement on the linker side, but definitely worth thinking about for small systems I guess.
All the best, Marcel