First of all, thanks for taking the time to look and improve my stuff, I know how it is.
Chain-Q wrote:mk79 wrote:Is there any mechanism of passing an option to the backend to select which style of output should be produced?
What do you mean by "style of output"? Assembler style? Not currently, on the backend, the m68k always produces GNU AS style assembler, even for vasm.
No, I mean the two methods of attaching the meta data, QemuLator header and XTcc trailer.
Yes, the optimizer completely skips the assembler blocks, including the dead-move elimination. If you want to optimize those, I'd still leave the parameter-move code in place, commented out maybe, or a small comment in its place, that the parameter is already at the right register, or something. This way the next person who comes around will probably understand better what is going on.
Yes, that's what I thought, too, but that's an optimization that can wait until the very end
mk79 wrote: 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.
This was already like this, for the BASIC loader version, .bss overwrote the relocation table after it has been used.
Oooh, of course you're right. So that's fine already, but then the relocation code should clean up after itself to zero .bss, does it not (at least in C this is the rule)?
I guess to see if we can keep this in the exe version or not, depends on the if the dataspace is allocated right after the binary when loaded, forming a continuous address range, or not.
Well, for normal execution a single memory block is allocated for both binary and dataspace, so the area is continuous.
There is one special case, EXE files can also be loaded as a so-called "thing", which can be executed multiple times. In this case only the dataspace is allocated for each instance, the code is shared. But of course this only works when the code uses relative addressing to its data area, for relocated code this is not an option in any case, so it doesn't matter either way.
Marcel, I also integrated your qdos.inc and qdosfunc.inc patches now, with some minor changes. It's mostly about spaces/tabs and other whitespace changes
I started writing the code in a TMUXed SSH session on the Mac with VIM as the editor but later switched to VS Code on my PC in order to not go insane. Might have scrambled the tabs a bit. What is the official tabs policy?
where in the commit message I "successfully" mistyped your name as "Marcus"
No worries, in the English speaking world I'm called Marcus so often it almost doesn't register anymore
the .map file generation during linking, this is again modified compared to the original patch, and instead of being always active, it's hooked up to some already existing compiler infrastructure. Activate with the -Xm command line switch. (This was actually also backported to other targets using vlink where it was also missing, so again, great.)
That's great, thanks!
Now the only big change remains is the migration away from the BASIC loader and move to executable. For a starter, is there more documentation about that QL header array you added to t_sinclairql.pas? I don't really like magic values.
IIRC you have QemuLator installed? Have a look at the manual, appendix II. The QDOS hdr_ fields are listed in the SMS reference manual chapter 7 "DIrectory Device Drivers". The first field hdr_length is skipped in QemuLator headers as it's superfluous, it starts with offset 4 (hdr_access):
Code: Select all
OFFSET LENGTH(bytes) CONTENT
0 18 “]!QDOS File Header“
18 1 0 (reserved)
19 1 $f (total length_of_header, in 16 bit words)
20 1 0 hdr_access field (unused)
21 1 1 hdr_type field (1 = EXE file)
22 4 x hdr_data (data space)
26 4 0 hdr_extra (unused)
30 end of header
Cheers, Marcel