The Sinclair QL Forum

Chain-Q wrote:I want to keep this style for the system unit, and the raw headers. For the user-visible qdos unit in qlunits, we can add overloaded functions, which would be more Pascal-ish.

function mt_inf(system_vars: ppbyte; ver_ascii: plongint): Tjobid;

would be equivalent with this:

function mt_inf(out system_vars: pbyte; out ver_ascii : longint): Tjobid;

I have no objections. If I follow you, the latter form would be in the QL Unit, "qdos", and would just call out to mt_inf in the system unit, yes?

I told you, my Pascal is not good!


Cheers,
Norm.

NormanDunbar wrote:If I follow you, the latter form would be in the QL Unit, "qdos", and would just call out to mt_inf in the system unit, yes?

That is correct. These wrappers will be there until ABI compatibility allows, so whatever application code gets written, can be more Pascal like. But I always tend to be careful with this and not take away the C-like functions, because whatever Pascal dictates for prettier syntax may be more limiting. For example, for an out or var parameter (i.e. parameters passed by reference) you cannot pass a NIL (null) value. And that is sometimes needed in some low level APIs. Maybe not on the QL tho', I'm not sure, still not an expert on this, but talking from experience on half a dozen other retro systems...

Also, as a heads up: on my request Frank Wille of vbcc/vlink/vasm fame actually implemented QL binaries support (both QDOS Header/XTcc header style) for Free Pascal in vlink, which I'm now testing as internal alpha. The main advantage will be - apart from yet another toolchain having basic support for the QL - is smaller relocation tables for Free Pascal code. For example the "Hello, World!" size will be ~2.5KB less, which is quite a big saving on a 10-odd KB binary. But it will require bleeding edge vlink. I'll try to keep the old code in the compiler though, until the new vlink gets released.

Chain-Q wrote:Also, as a heads up: on my request Frank Wille of vbcc/vlink/vasm fame actually implemented QL binaries support (both QDOS Header/XTcc header style) for Free Pascal in vlink, which I'm now testing as internal alpha. The main advantage will be - apart from yet another toolchain having basic support for the QL - is smaller relocation tables for Free Pascal code. For example the "Hello, World!" size will be ~2.5KB less, which is quite a big saving on a 10-odd KB binary.

a) that is fantastic!
b) how come the savings is so big? Does ist use a compressed format?

All the best, Marcel

mk79 wrote:how come the savings is so big? Does ist use a compressed format?

No, not really. Instead, the old relocation table was quite wasteful, but it was also very simple. Basically it was just a series of longwords with the relocation offsets. The new format is basically if the next byte is zero, then the next 4 bytes contain an offset like before, if not zero, then it's just a byte delta from the previous offset. Obviously, a most of the relocation positions are within a byte length from each other, so it adds up to significant savings. The expense is of course somewhat more complex relocation code, which also has to be able to read unaligned dwords from the table. But it's still worth it, and the larger the binary the bigger the savings, of course.

Also, from vlink perspective, the relocation table is entirely optional, and it can still generate a QL binary without it.

Also, as a heads up: on my request Frank Wille of vbcc/vlink/vasm fame actually implemented QL binaries support (both QDOS Header/XTcc header style) for Free Pascal in vlink

So we are getting vbcc for QL out of this too?

Chain-Q wrote:

mk79 wrote:how come the savings is so big? Does ist use a compressed format?

No, not really. Instead, the old relocation table was quite wasteful, but it was also very simple. Basically it was just a series of longwords with the relocation offsets. The new format is basically if the next byte is zero, then the next 4 bytes contain an offset like before, if not zero, then it's just a byte delta from the previous offset. Obviously, a most of the relocation positions are within a byte length from each other, so it adds up to significant savings. The expense is of course somewhat more complex relocation code, which also has to be able to read unaligned dwords from the table. But it's still worth it, and the larger the binary the bigger the savings, of course.

Cool, that was what I meant, didn't expect it to be ZIPed or anything All exciting developments!

Cheers, Marcel

XorA wrote:So we are getting vbcc for QL out of this too?

Not from me, sorry. And to my knowledge Frank is not looking into it either. But whoever picks up that challenge is one step closer now to have something "production ready". At this point I think it's only some libc support is missing, as vbcc is a fully capable embedded compiler, and in FPC either there's not that much QL specific apart from the library code and the linking stage, and whatever extra is there is usually more Pascal and compiler specific, and you can go without it. And for a libc, one can probably repurpose large parts of C68/QLGCC libc. Go go go!

Chain-Q wrote:

XorA wrote:So we are getting vbcc for QL out of this too?

Not from me, sorry. And to my knowledge Frank is not looking into it either. But whoever picks up that challenge is one step closer now to have something "production ready". At this point I think it's only some libc support is missing, as vbcc is a fully capable embedded compiler, and in FPC either there's not that much QL specific apart from the library code and the linking stage, and whatever extra is there is usually more Pascal and compiler specific, and you can go without it. And for a libc, one can probably repurpose large parts of C68/QLGCC libc. Go go go!

With a compiler and Linker as a C coder by trade Id be happy to work on the C library.

Just as a quick heads up, in SVN r49233, I fixed an FPC inline assembler bug (m68k specific), which in some of my test builds caused the relocation code to fail for bigger than 32K executables, and even trash innocent memory in the process. (An index register was interpreted for .w size, rather than .l size, whoops...) So I advise everyone to rebuild your compiler if you try to build more complex code.

More heads up: I've just added (r49239) a dummy sysutils and classes unit. These are basically the two core units for Object Pascal features. Basically this is what is needed for Delphi-level code. However, it comes with a price, which is slightly more code bloat. Especially sysutils unit grew really large over the years, becoming kind a second "system unit" where all sorts of random massively interdependent system utilities and support code gets thrown in. Any code using the sysutils unit will touch into the 100KiB range easily. This isn't only FPC's fault, but it's kinda the structure and API we inherited to be able to compile existing code. But this also makes such code unfeasible to run on an unexpanded QL. There isn't a way to avoid it, as anything more advanced even inside FPC will depend on sysutils. So, yeah. It will of course still work happily on a memory expanded QL.

Anyway, this can be also considered also as a step towards "more advanced" systems, like producing binaries which are aimed at running on QPC and SMSQmulator. At the same time, volunteers are welcomed to implement the missing/stub functions. Which is basically everything in rtl/sinclairql/sysutils.pp at this point.

Of course using these is entirely optional. One can still write code directly for the QL API to keep binary size low, if has to run on an unexpanded QL.