I rather suspect that as applications get more complex than writeln('HelloWorld!'); the size discrepancy will come down. Even with C68, a hello world type program seems quite big compared to assembly.Ruptor wrote:30K for Hello World that is half the microdrive capacity is funny
That was the first thing I tried and it didn't work... but now it does, spookyChain-Q wrote:Congrats for being the 2nd person who ever managed to get this shebang somewhat working.mk79 wrote:YayWhen I find the time I might try to implement EXE support. Of course the real work will be in the libraries...
BTW, in the currently committed version, I think a simple Pascal-ish writeln('Hello, World!') should work to
Yes, exactly, this is what I meant. More complex programs usually suffer less from this in relative terms. (Well, depends a lot on how you write those complex programs, but overall it's still true.)NormanDunbar wrote:I rather suspect that as applications get more complex than writeln('HelloWorld!'); the size discrepancy will come down.Ruptor wrote:30K for Hello World that is half the microdrive capacity is funny
Well, maybe there was some build issue, or if you tried with standard QL, it didn't have enough memory for some reason, maybe because the code was loaded twice, or something. (The startup code just exits silently if it cannot allocate stack for itself.) But it's just an idea.mk79 wrote:That was the first thing I tried and it didn't work... but now it does, spookyChain-Q wrote:BTW, in the currently committed version, I think a simple Pascal-ish writeln('Hello, World!') should work to
So I had to fix that first (compiler.diff).Thanks Marcel. That's a good idea, as the XTcc trailer is the standard QL cross compiler output, which one gets from QDOS-GCC also, and from cross assembly. Classic tools for native filesystem access like qxltool also support the XTcc trailer rather than the Qemulator header. SMSQmulator NFA also supports the XTcc trailer.mk79 wrote:Alternatively there is some commented out code that can produce the XTcc trailer known from XTC68 instead.
Yeah, this is a nice catch. 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. And no other port needed the internal assembler so much before as the QL port. Your patch was very helpful for a quick identification of where the problem was, but instead of using it directly, I ended up refactoring the entire BuildConstant method in ra68kmot.pas. See here and here.mk79 wrote:Well, I spent some time on it now. You know things will go well when one of the first things you try results in an "internal error" of the inline assembler... it simply crashed anytime one wants to use "dc.b" or similar statements
Looks overall OK, but I haven't looked this one in detail yet.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.
This is a great idea, but probably should be done slightly differently. However, just as above the patch is very helpful, and I'll slightly modify it when I'll integrate and commit it. (BTW, you can pass any argument to the linker via the -k command line argument already, so you could have used it to get the map file from the linker, but it's an useful feature, so lets have it.)Also, a MAP file is now produced to help debugging.
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. Free Pascal doesn't just pass arguments on the stack, but the first two "pointer" type arguments are passed in registers a0/a1, and the first two "ordinal" type arguments are passed in registers d0/d1. Remaining arguments are passed on the stack. The arguments are passed from left to right. This is important for example when you re-shuffle the input parameters for a QDOS trap/vector call, because if you don't keep it in mind which parameter might be passed in which register, then you could overwrite the parameter accidentally. See the m68k-specific calling convention and registers documentation here.Furthermore I implemented most of the file system API, though I haven't tested most of the code so far. That must wait for another time...
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 
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.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.
Is there any mechanism of passing an option to the backend to select which style of output should be produced?Looks overall OK, but I haven't looked this one in detail yet.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.
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, thoughI 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.
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.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.
