QL / PASCAL

[mk79]

I was going to post some really bad Pascal code, but the Forum ate my first reply with a 403 Forbidden error.

The forum is more intelligent than we give it credit

[NormanDunbar]

Glad that your PICNIC went well. And that's a quite nice document you've got there. It really extends on a lot of details for beginners, which I did not want to include into the wiki. But if you find some final location for it somewhere, I'll gladly link it from the FPC Wiki page.

The document will be available on my GitHub releases area as will the LyX/LaTeX source "soon". Anyone can have it, so feel free to link to it -- when I post the link. I'll be intending to keep it up to date too. Corrections etc are all welcome.

Ok, the current version of the document is now on GitHub. There will always be a "latest" version available from https://github.com/NormanDunbar/FPC-Cro ... ses/latest assuming all goes well. At present it's flagged as a pre-release.

Grab the PDF only if you don't need/want my LyX source code. Grab a source package if you do, you get the PDF in with the source so there's no need to grab the PDF as well.


Cheers,
Norm.

[Derek_Stewart]

Hi,

I downloaded the FPC-CrossCompiler-QL document in PDF format and started afresh with the installation, previousily, I had downoladed by SVN FPC source code and compiled, rather thsn download a compiled version.

Using the guide, I followed the intructions and managed to compile the Crosscompiler.

But when I tried to compile a QL programme: hello.pp

gave errors indicating the ql units could not be gound.

I found copying the commands from the file introduced extra spaces in the pasted text.

Maybe this is the problem with the FPC config file, with my editing of the fpc.cfg file.

Can the crosscompiler display the required paths indicated in the config file?

[NormanDunbar]

I've just uploaded the "completed" document. It's at https://github.com/NormanDunbar/FPC-Cro ... ses/latest as usual, you should see version 1.0.

I found copying the commands from the file introduced extra spaces in the pasted text.

Interesting, and yes, I see that too. Weird! I suspect it's something to do with, possibly, the PDF being UTF perhaps? I don;t see it when copying the document text, only the code. I'm not sure what to advise, sorry.

However, there is a Sinclair QL page on the FPC Wiki at https://wiki.freepascal.org/Sinclair_QL where the config file contents can be easily copied and pasted without additional spaces being added. This might help until I see if there's a way to get rid of the extra spaces.


Cheers,
Norm.

[Chain-Q]

A quick fix for today. The existing MT_INF in qdos.inc has the system variables address coming back via a pchar and the ASCII version via a plongint. They are the wrong way around. Patch 6 fixes the problem.

Sorry Norman, but I'm pretty sure this patch is wrong, but having said this, I'm not saying the original version in there is entirely correct. But there I copied the mt_inf() function signature from QL-GCC libc actually.

If I understand properly the description, the ver_ascii info is returned in D2, which means the short 4 char ascii string is actually in the register itself, and not pointed by the register. The fact that the system vars are PPChar is not elegant, perhaps in Pascal it should be a PPointer (pointer to an untyped pointer), or PPByte (pointer to a pointer of bytes) instead. But as I said the function signature was copied from QL-GCC, where it had a char **, so I went with PPChar. That could be fixed/changed indeed, but ver_ascii as PLongint is correct. You need to pass a pointer to a longint (or well, any storage 4 bytes long) to make this work. And passing PChar is dangerous, because the resulting characters won't be zero terminated, so writing them can cause issues, unless the pchar buffer is a fixed size array.

If we really want to make this elegant and Pascal-ish, I'd just make another function signature which allows these as pass-by-reference arguments, and then make it pass an array of 4 characters as reference instead. but because in FPC you can just typecast a longint to a 4 byte array and vice-versa, I think this is a really minor issue. Plus the compiler protects you, and gives an error in case you want to cast a wrong sized array.

This is how it works (with the original function signature):

Code: Select all

program inf;

uses
  qdos;

type
  Tver = array[0..3] of char;

var
  job_id: longint;
  ver_ascii: longint;
  system_vars: pbyte;

const
  SV_IDENT = $00;
  SV_TVMOD = $32;
  SV_RAND  = $2e;
  SV_PTYP  = $a1;

begin
  job_id:=mt_inf(@system_vars,@ver_ascii);

  writeln('Job ID:',job_id);
  writeln('Version: ',hexstr(ver_ascii,8),' ',Tver(ver_ascii));

  writeln('System vars at: $',hexstr(system_vars));
  writeln('Identification: $',hexstr(pdword(@system_vars[SV_IDENT])^,8));
  writeln('Processor type: 680',hexstr(system_vars[SV_PTYP],2));
  writeln('Monitor mode: ',system_vars[SV_TVMOD]);
  writeln('Random number: ',pword(@system_vars[SV_RAND])^);
end.

The output of this code looks like this:

I mean, the castings to get the various offsets are slightly ugly this way. The right way would be to define a record type, where you can just reach all fields with the right offsets, or, worst case have a GetByte/GetWord/GetLong() helper function which would contain/hide all the messy pointer gymnastics. But as far as I'm concerned, maybe the system_vars argument type should be changed to PPbyte, instead of PPChar, but nothing else.

I was going to post some really bad Pascal code, but the Forum ate my first reply with a 403 Forbidden error.

No Pascal code shaming! All Pascal code is beautiful! (Ok, maybe not... )

[Chain-Q]

Ok, the current version of the document is now on GitHub. There will always be a "latest" version available from https://github.com/NormanDunbar/FPC-Cro ... ses/latest assuming all goes well.

I added a link to that page into: https://wiki.freepascal.org/Sinclair_QL#Building

[NormanDunbar]

The forum is more intelligent than we give it credit

AI?

[NormanDunbar]

I added a link to that page into: https://wiki.freepascal.org/Sinclair_QL#Building

Thanks.

Cheers,
Norm.

[NormanDunbar]

Sorry Norman, but I'm pretty sure this patch is wrong, but having said this, I'm not saying the original version in there is entirely correct. But there I copied the mt_inf() function signature from QL-GCC libc actually.

Hmmm. From your example, I see your point, I think.

Happy that the ASCII version needs a terminator. But the system variables address is a longword surely? Or at best a pointer to a byte?

I do prefer it to be a pointer to a record though, that sounds like a better idea.

I'll revert my changes for now then.


Cheers,
Norm.

[Chain-Q]

But the system variables address is a longword surely? Or at best a pointer to a byte?

The address itself is a longword for sure, but it points to a series of bytes. As in, in that sequence not all fields are longwords, or 32bit aligned actually.

If in my example the variable system_vars was a PLongint; that would mean when I dereference it with an index, say: system_vars[4], this would mean my offset gets multiplied by four, and would access the field at byte-offset 16. Which is not what we want, because the doc-specified offsets are in bytes. There are also fields what are not longword (32bit) wide, but words or even bytes, so therefore it must be pbyte. I mean, we both agree that the most elegant version for this would be a struct/record, which maps the system variable fields, but until it is absent, system_vars as pbyte is probably the best solution. Therefore a the function call needs a ppbyte it its signature (pass a pointer, which points to the pointer of bytes, which is the low-level/C-ish way to pass a reference to our variable.

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;

On the ABI level these two functions are identical, but the fact that these are out parameters, change the Pascal syntax slightly, and probably make it prettier/more readable for user programs. But it still a bit abstracts what's happening underneath, so for the system unit itself, I _personally_ prefer the low-level style, but if there are disagreements, we can do a refactor.