QL / PASCAL

Anything QL Software or Programming Related.
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: QL / PASCAL

Post by NormanDunbar »

Just a quickie, the document on building the Cross Compiler had a minor error in it at the end where the QL Units were copied to the installation folder required. The end of the command was missing, not good. A few other typose and speling erors have been fixed. ;) Version 1.1 is online now.

As ever, the link to the latest version is https://github.com/NormanDunbar/FPC-Cro ... ses/latest. This will not change, the latest version of the document will always be on that link.

As also ever, you don't need the zip or gz files, they contain the source code for the document, you only need the PDF file.

Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QL / PASCAL

Post by mk79 »

Chain-Q wrote: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.
Exciting :)

Norman, I give you first shot if you want to get your hands dirty with it :-P With the schools more or less closed I struggle to keep my main job going well enough these days and the little time that is left I spend on finally getting QL-SD out of the door. But otherwise I will eventually do some work on it...


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: QL / PASCAL

Post by NormanDunbar »

mk79 wrote:Norman, I give you first shot if you want to get your hands dirty with it :-P
Gee! Thanks! :D :D

No, I'm happy to make a little contribution as and when I can. I did manage to have a quick look yesterday before being dragged off by MrsD to "get a life". She's out walking today, so I'm on housework and end of year accounts duties for our business.

I'll pick it up when I can and I'll post diff files on this thread where you, Chain-Q and anyone else interested can pick and choose as they wish.


Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
Chain-Q
Chuggy Microdrive
Posts: 62
Joined: Mon Nov 16, 2020 1:10 pm
Location: Berlin, DE, EU
Contact:

Re: QL / PASCAL

Post by Chain-Q »

Sure, patches here are totally welcome as in the previous format.

Few other questions:

- 1., the compiler now generates executable files with the .exe extension. However, I think this isn't a QL custom? As you even need to put the binary name into quotation marks (like "win1_hello.exe") in this case. It's perfectly possible to change it, or even have just a different extension separator instead of the dot. How should this work?

- 2., Now the system unit automatically says "Press any key to exit" on program exit. I do not think this is ideal, especially now that we have ways to wait for input, and more can be added in the user program very easily. What are the opinions on this? (As a side note, if I just ex "win1_myapp.exe" in the emulator, I get back the prompt while the job itself is stuck on waiting an input. I couldn't figure out how to reactivate the job, so its stdin can be fed with data, like a keyboard press.)

- 3., I don't really understand how the channels thing should work. When the job is passed channels, should it take them as stdin/stdout on the library level? Or just expose them via some API? How to decide which channel is input or output? Can it have more than two channels passed? What do to then? Obviously, this also affects point 2, because if we have an externally specified stdin, say, a file, then the program will stuck forever there waiting for an input, if there's nothing more left.

Just a few from the top of my head. :)


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: QL / PASCAL

Post by NormanDunbar »

1. The .exe file thing is probably not a huge problem these days. Given that we are cross compiling, the file name created on Windows/Linux/etc is easily renamed for transfer to the QL. In addition, the emulators all/mostly can cope with dots in filenames. QPC certainly does. I'd say this is a non-problem. ;)

2. The C68 compiler for the QL also asks for permission to exit, if the user configured it to do so. Usually there's an option in the program to exit anyway - for example, in an editor, we can press the correct keys to exit, or click on a button/icon/whatever to quit. I'd say that it's fine, but perhaps an option could be added to allow the program not to wait, and the developer could configure as required?

The problem is that under SMSQ the system will save the underlying background when a new window opens then restore it when it closes. Hidden jobs cannot (normally) update their screens unless they are on top of the stack of jobs, and have their window on top. When we execute a job, like a cross compiled Pascal program, it opens a window, runs, then on exit, the area of the window will be restored to its previous content. We would need the prompt to enable the user to see what the output was before it vanishes.

Provided a job is showing a cursor, usually a flashing one, then you can press CTRL-C (I know!) to switch tasks to that flashing cursor. Under SMSQ we can "pick" a job to the top of the pile, and hopefully "press any key" to let it continue and exit. Failing that we can "RJOB" it to remove it from the system.

The EX or EXEC command starts a job running and returns to the caller (SuperBASIC/SBASIC) the job will run to completion and even if it exits with an error, SuperBASIC/SBASIC might not be able to receive the error code. EW or EXEC_W executes the job, but stays "connected" until the end. When this job exits with an error code, it will be reported by SuperBASIC/SBASIC.

3. Channels, passed on the command line. See this doc for details, and pretty pictures! https://github.com/NormanDunbar/QLAssem ... ge_001.pdf. Chapter 3, The EX Files is where you want to be. There are, I think, examples covereing ever possible manner of passing channels or filenames to a task. :D

Channels can be passed as filenames, or actual # numbers and such like, and it gets a little confusing. If I execute a file thus:

Code: Select all

EX my_prog.exe, abc.txt, def.txt
Then "abc.txt" will be opened for input and passed as stdin, while "def.txt" will be opened for writing and passed as stdout.

However, it's possible to pass more than two files (not that I ever have) and I'm not 100% convinced what mode they are opened in.

Things like this are not handled well, unless the developer specifically coded for it:

Code: Select all

EX my_prog.exe, abc.txt, def.txt; ">>fred.log 2>&1" 
HTH

Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
tofro
Font of All Knowledge
Posts: 2688
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QL / PASCAL

Post by tofro »

Chain-Q wrote: - 1., the compiler now generates executable files with the .exe extension. However, I think this isn't a QL custom? As you even need to put the binary name into quotation marks (like "win1_hello.exe") in this case. It's perfectly possible to change it, or even have just a different extension separator instead of the dot. How should this work?
Actually, there's no convention on filename extensions in QDOS - All the information the system needs is in the file header. I have developed the habit to use "_exe", however.
Chain-Q wrote: - 2., Now the system unit automatically says "Press any key to exit" on program exit. I do not think this is ideal, especially now that we have ways to wait for input, and more can be added in the user program very easily. What are the opinions on this? (As a side note, if I just ex "win1_myapp.exe" in the emulator, I get back the prompt while the job itself is stuck on waiting an input. I couldn't figure out how to reactivate the job, so its stdin can be fed with data, like a keyboard press.)
C68 solves the same problem elegantly by providing a global variable "char *_endmsg" containing the "Press any key" in its C library. The linker will pull in this symbol (and display the message) if it's not defined in a program. You can override this linker symbol in your own program by defining your own string or setting the pointer to NULL, which disables both the message and the wait for keypress. If something similar (weak, overridable library symbols) is possible in FreePascal, it would be the most convenient mechanism.
Chain-Q wrote: - 3., I don't really understand how the channels thing should work. When the job is passed channels, should it take them as stdin/stdout on the library level? Or just expose them via some API? How to decide which channel is input or output? Can it have more than two channels passed? What do to then? Obviously, this also affects point 2, because if we have an externally specified stdin, say, a file, then the program will stuck forever there waiting for an input, if there's nothing more left.
With channels (and the initial console and the command line in general) I'd take another sneak peek to C68:

C68 has a global function pointer variable "_consetup()" which is called from the startup code, if it's not overwritten to NULL by a global initializer. This routine, again is pulled from a library, or statically disabled from your program by declaring it as "extern void (*_consetup()) = NULL;" . Alternatively, you can override the lib routine by initializing the function pointer with a pointer to your own routine.

Note that QDOS has no support that would parse a command line for you (or, additionally, expand wildcards or similar like in Unix). A program has to supply it's own code for that.

Channels handed over, pipes opened I quote the manuals:
So far as EX is concerned, the distinction is that a special program must contain the code to open its own I/O channels. At the start of execution a standard or non-standard program will have the following information on the stack:

word the total number of channels open for this Job
[long the channel ID of the input pipe, if present]
(long the channel ID of each filename given in prog_spec)
[long the channel ID of the output pipe, if present]
word the length of the option string or 0
[bytes thebytesoftheoptionstring]

If there is just one channel open for a Job, then it is opened for read/write unless it is a pipe in which case the direction is implied in the command.
If there is more than one channel open for a Job, then the first channel is the primary input (opened for read only), and the others are opened OVERWRITE. The last channel is the primary output.

A Job should not close the channels supplied, but, when complete, it should commit suicide. Each Job is owned by the next one in the chain, so that when the last job has completed, the entire chain is removed. Committing suicide in this way will put an end of file in the output. Thus an end of file from the primary input should, directly or otherwise, indicate to a program that the data is complete.
Note the handed in channel IDs would need to be converted to something usable in Pascal, like a TEXT of FILE.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QL / PASCAL

Post by mk79 »

I'll add my 2e-01 cents, too.
Chain-Q wrote:- 1., the compiler now generates executable files with the .exe extension. However, I think this isn't a QL custom? As you even need to put the binary name into quotation marks (like "win1_hello.exe") in this case. It's perfectly possible to change it, or even have just a different extension separator instead of the dot. How should this work?
Executables are determined by meta-data, so in principle it doesn't matter. Most executables either have no extension at all or "_exe". But in a foreign land one should obey foreign customs, so ".exe" is the best choice I think. QPC does translate that transparently into "_exe" by default, but no other emulator does.

Besides, in SMSQ/E "hello.exe" can be typed without quotes, this is a pure QDOS problem.
- 2., Now the system unit automatically says "Press any key to exit" on program exit. I do not think this is ideal, especially now that we have ways to wait for input, and more can be added in the user program very easily. What are the opinions on this?
If the weak linking Tofro mentioned is an option then that would be ok. If not it should be removed.
(As a side note, if I just ex "win1_myapp.exe" in the emulator, I get back the prompt while the job itself is stuck on waiting an input. I couldn't figure out how to reactivate the job, so its stdin can be fed with data, like a keyboard press.)
This is again just QDOS without the "pointer environment" loaded which does the window handling. You can switch jobs using CTRL+C.
- 3., I don't really understand how the channels thing should work. When the job is passed channels, should it take them as stdin/stdout on the library level? Or just expose them via some API? How to decide which channel is input or output? Can it have more than two channels passed? What do to then? Obviously, this also affects point 2, because if we have an externally specified stdin, say, a file, then the program will stuck forever there waiting for an input, if there's nothing more left.
This is the quote from C68:
The first channel is allocated to stdin, and the last one to stdout. If three channels are supplied then the second one is allocated to stderr. These channels are available at all I/O levels (see later). Additional channels are initially available only at Level 1 I/O (described later). They are allocated file descriptors starting at 3.
Cheers, Marcel


User avatar
Chain-Q
Chuggy Microdrive
Posts: 62
Joined: Mon Nov 16, 2020 1:10 pm
Location: Berlin, DE, EU
Contact:

Re: QL / PASCAL

Post by Chain-Q »

Uh, that's a lot of info to process, thanks all three of you for the answers, I'll just try to answer the few, randomly, which I have an answer for currently. :)
mk79 wrote:Most executables either have no extension at all or "_exe". But in a foreign land one should obey foreign customs, so ".exe" is the best choice I think.
But well, FPC has a tendency to follow the target platform convention instead. So of course it doesn't do .exe on Mac or Linux, or Amiga for that matter, on Atari for example it will generate '.TTP' or '.GEM' extension, depending on if you compile a GUI program or not, etc. And I get that on QL the dot doesn't serve as separator, but it's not a problem. Anyway, I'm just saying that it's possible to change. But whatever y'all think. :)
NormanDunbar wrote:Provided a job is showing a cursor, usually a flashing one, then you can press CTRL-C (I know!) to switch tasks to that flashing cursor.
Well, that's the thing. In this case FPC doesn't show a blinking cursor, just tries to do a blocking read from STDIN. Maybe that's not opened with the right settings or something, but it certainly works with EXEC_W. No idea. :) Another point to look into then. (Trying with Q-emuLator still. I don't know, trying with such a tiny system has its charm, for me...)
tofro wrote:C68 solves the same problem elegantly by providing a global variable "char *_endmsg" containing the "Press any key" in its C library. The linker will pull in this symbol (and display the message) if it's not defined in a program. You can override this linker symbol in your own program by defining your own string or setting the pointer to NULL, which disables both the message and the wait for keypress. If something similar (weak, overridable library symbols) is possible in FreePascal, it would be the most convenient mechanism.
Yeah, something like this is certainly possible, but probably not with symbol override as FPC doesn't really support weak symbols (there are ways, but it's just very messy), so "Press any key to exit" as string will always end up in the executable anyway, even if it's not used in the end, but something similar can be easily invented. Same with the consetup idea, although I'm not sure how many internal APIs there need to be exposed to work well. So that requires some thought. But it's not impossible.

The channels stuff still needs some more processing from me to fully understand, but it's already a lot more clear, and it's quite helpful what y'all wrote, thanks.

Few bits from me: courtesy of Marcus Sackrow, the other suspect behind FPC Amiga port beside me (I'm more a compiler and low-level guy, he likes to work on GUI stuff and high level), there's now a regular QL build with a Linux/x86-64 cross compiler, mainly for the purpose to notice immediately if the build breaks due to some changes made by others. I will get e-mail notified in this case. But regardless, the build outcome is available here, in case someone wants to try: https://build.alb42.de/fpcbin/, search for the fpc-?.?.?-m68k-sinclairql.tar.gz :) (Not linking the file directly, because the compiler version might change in the future, and the file is regularly updated.) The Linux/x86-64 binary of FPC works on any distro, because it doesn't use any libraries from the system, not even libc, it goes directly to the kernel syscall interface. So any Linux works. One still need to supply vasm/vlink binaries though.

Also, this made possible another neat trick - Marcus added Sinclair QL support to his online FPC compiler, where one can just paste Pascal snippets, and then download a QL binary. :) It's available here: http://build.alb42.de/onlinefpc/ Select "Sinclair QL" from the drop down menu to get a QL binary. I wonder if this is the world's first online compiler for the Sinclair QL... :)

Also check Marcus' blog, he posts a lot if interesting stuff he works on, almost all of them Pascal related. It shows the things FPC makes possible on low end or niche systems, with a single developer. (My recommendations: an OpenStreetMap client, a spreadsheet app with .xlsx support, a Wolfram Alpha frontend, or a small raycaster engine.) Such stuff should be possible for the QL (and compatibles) if we manage to get the support libraries advanced enough, that is. ;)


User avatar
Chain-Q
Chuggy Microdrive
Posts: 62
Joined: Mon Nov 16, 2020 1:10 pm
Location: Berlin, DE, EU
Contact:

Re: QL / PASCAL

Post by Chain-Q »

Oh, and one slightly offtopic news I forgot, whoever is interested to work on VBCC for the QL, I mentioned this to Frank Wille and they should contact him directly. He said to me that access to vclib source is possible for serious contenders. It just needs a startup code (feel free to reuse my code from FPC startup for relocation, I'm happy to relicense it for VBCC/vclib, even if FPC itself is GPL), and access to the OS API so headers and similar, then just implement a layer of calls in libc. It's all boring dirty work, but really beneficial on the long run. His e-mail is on the vasm and vlink webpages.

The new linker support for QL is actually already in the vlink daily snapshot, Free Pascal can even use it with a hidden :P command line switch and a rebuilt startup code to use the packed relocation format.


User avatar
XorA
Site Admin
Posts: 1359
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: QL / PASCAL

Post by XorA »

Chain-Q wrote:Oh, and one slightly offtopic news I forgot, whoever is interested to work on VBCC for the QL, I mentioned this to Frank Wille and they should contact him directly. He said to me that access to vclib source is possible for serious contenders. It just needs a startup code (feel free to reuse my code from FPC startup for relocation, I'm happy to relicense it for VBCC/vclib, even if FPC itself is GPL), and access to the OS API so headers and similar, then just implement a layer of calls in libc. It's all boring dirty work, but really beneficial on the long run. His e-mail is on the vasm and vlink webpages.

The new linker support for QL is actually already in the vlink daily snapshot, Free Pascal can even use it with a hidden :P command line switch and a rebuilt startup code to use the packed relocation format.
That was me, just about to go on a weeks hols, but I would certainly be interested in working on a modern C compiler for QDOS-SMSq/e. It's been a while since I wrote a C library so I could do with the practice. Ill ping him when I get back!


Post Reply