QL / PASCAL

[vanpeebles]

Yuck OO!

[Ruptor]

Good old Object Orientation, Tony Tebby will be rather cross I imagine! I remember reading in QL Toady, just how much he hated OO. (I think it was QL Toady!)

I puke when someone mentions using OO but not because OO is wrong it is the bad implementation of it that has resulted in OOdles of unnecessary code. The efficient implementation of Object orientated design that is supposed to limit the movement of data transfers to give the most efficient code has been lost in translation and nobody seems to care they are quite happy to generate Gigabytes of code for a task that can be done in 1K as this thread shows. There is noway Lazarus could run on a standard QL like a QL Pascal can. How many people have the rare QL clones? A 100K?

[NormanDunbar]

There is noway Lazarus could run on a standard QL like a QL Pascal can.

To be fair, Lazarus is an IDE wrapped around the Free Pascal compiler, which gives PC users something equivalent to EasyPtr4 for the QL. Free Pascal is the compiler equivalent of Pascal on the QL.

I used to have Metacomco pascal and you didn't "run pascal", you had to develope in an editor, save it, then compile it with the pascal compiler. No IDEs in them thar days! And as for gigabytes....I started on a ZX-81 with 1KB of RAM, all these QL users with their 128 KB? Pah!

I was playing with FPC this morning - god I'd forgotten how fast a Pascal compiler is.


Cheers,
Norm.

[Chain-Q]

What is a Job on a QL? Full, gory, details can be found at http://qdosmsq.dunbar-it.co.uk/doku.php ... :jobs:jobs - but feel free to ask if there's anything you don't understand or need more information on. Basically, a job is a chunk of code, structured in a specific way, which executes as an individual process/task in a QL. It should be position independent as there's no way it will know the execution address when activated.

So the code can be even shuffled around after loaded in memory between multiple runs? So even relocation-after-first-activation cannot work? That's not good news (for me), more work on the 68k back-end then... There is some support for position independent code as this has been required by the - also experimental and just for fun - PalmOS support for example, but working with long displacements (i.e. code an data which is more than 32K away from the base pointer) are definitely an issue on a plain 68000 for now.

Re cross compiling, cross compilers (well, the one I know of!) write a pair of long words (4 bytes each) to the end of the generated code in a format known as XTcc:

Code: Select all

dc.l 'XTcc'
dc.l required_dataspace

Other QL utilities such as unzip will be able to read these two long words and configure the appropriate file header in the QL version to have the correct data space requirements. These are job files, and when EXECuted on a QL will create a job.

Hmm, so what is a "dataspace"? I imagine it's the QL terminology for the .bss section of the binary, no? As in, uninitialized (or initialized to zero after loading) data. So what Free Pascal currently does that in the BASIC loader it allocates enough space for the .code + static .data + .bss sections, but the .bss (given it's all zero) is just omitted from the binary, and instead the relocation tables are appended after a merged code + data section. The startup code takes the relocation table, relocates the binary, then because it knows it has enough space for the .bss at the end, it will just initialize the .bss section to all zero, right after the code + static data area, overwriting the relocation tables, which are no longer needed. This is quite a hack, I know, but it made a significant difference to the binary size and memory requirements, which seemed to be important for a stock QL with only 96K RAM... But again, I might be completely off-track here, as the interest might not be at supporting the stock QL.

Now, I also imagine this entire approach collides with this data space allocation thing, so will have to be reworked then. Or?

QL Floats are just weird. The C68 stuff you have "ripped off" is public domain. You can find the current status of just about any QL software by looking on the QL Wiki at qlwiki.qlforum.co.uk. For C68, the page you want is https://qlwiki.qlforum.co.uk/doku.php?id=qlwiki:c68 and scroll down to the bottom.

Turbo Pascal had its own 48bit float format back in the days, but I'm not even sure that's the same as the QL float (minus the endianness difference). But Free Pascal doesn't support that either. Public Domain is ok, I'll attribute the code anyway then, and probably will leave it off from the RTL, and put it into a QL-support package elsewhere on the source tree. The runtime lib mostly deals with file and text I/O, and memory allocation, so doesn't really have to know about floats.

If you are still unhappy, then this is all my own work (so, not great then!) and you are welcome to take it, use it, abuse it as you see fit.

Thanks, it's generous, but I think this is the conversion the other way around from qlfloat to double. Which actually still might be useful, so thanks.

[Chain-Q]

By the way, living in Germany provides the chance to meet, once the pandemic is under control.

Yeah, lets hope so! My German needs even more practice than my English, so I'll take a chance to do so for sure.

Recently I had a short but fascinated look at NetBSD/68k, because it supports a plain 68000 target with a primitive MMU. And not only that, but it even has a complete distro - which would save much work compared to Linux if I want it on the Q68. (Easier to add a primitive MMU than dealing with ucLinux.)

That sounds interesting. What is this primitive MMU? Because the Linux/68k guys are trying to "beat" some sense into the Vampire/Apollo core people, to support some kind of MMU, so they can run Linux on the thing. I'm not a big fan of the Vampire for several reasons, but regardless, if there's a shortcut for them to still get something working that might be interesting for the whole m68k community.

If you like the Q68, and it has a good chance to be actually used, not just collected, I will see what I can do...

Yeah, sure, I know. I don't want to make big promises. The entire QL thing is very new for me, so I don't know how much I'll be into it mid-term. And then there's time... My time-expander project to make a day 72 hours is still not ready, but I'm working on it... But I checked the Q68, it's a nice little board, I like it. Lets see later how this goes, and thanks for the possibility/offer/mention regardless.

C cross compilers just append the characters 'XTcc' after the binary, followed by 4 binary bytes with the data space.

This sounds good, but see the problem (maybe) with position independent code and the relocation tables I detailed in my other answer above.

The Q68 has 32 MB RAM, but it's only about 68030 / lowend 68040 speed.

I know someone who uses FPC and the text-mode IDE on a 68030/50Mhz in an Amiga 1200, with I think 32MB RAM. Maybe 64? It certainly works for single-person projects, but it's not fast. I think the "Hello, World!" compile on that system takes about 30 seconds, mostly because of loading and parsing the system unit (the core of the RTL), which is positively huge, then about half that time is spent in assembling and linking, especially linking, so I blame vlink for that. The good news, is, it doesn't get much worse with slightly more complex projects either. But do not expect something like Lazarus or even FPC itself to compile on that system. Talking about vlink, a QL-native Free Pascal will also need vlink/vasm ported, because the internal assembler is not there for 68k yet and the internal linker would need specific QL support added anyway.

[Chain-Q]

I'm highly impressed with the whole project and downright thrilled that there is a QL cross compiler.

Yeah, thanks in the name of everyone who works on FPC and Lazarus, and I'm glad one of my dumbest (according to me) idea still make someone thrilled.

Do check out QPC, it's the emulator I've been developing for the last 25 years. It's free now (formerly 125€) and uses the much advanced OS SMSQ/E (still QDOS compatible). The emulation core was written in pure assembler at a time when 486s were all the rage, but I think it's still among the fastest for the QL. Oh, and it is 68020 compatible.

Sounds cool. Now I see there's a macOS bundle even? Somehow the name "QPC" put me off, and expected there's only a Windows version available, or something, and I do not have a Windows PC at hand. But will definitely check it out.

I'm also one of the main developers of the SMSQ/E operating system and happy to help out.

That sounds great that an OS developer is available for questions, who even knows and understands Pascal, or doesn't downright dismiss it (been there)... As soon as the entire target is in the SVN and can be compiled by other people too, some code review and feedback regarding the library code would be nice. Maybe we can patch up some chat or a Zoom/Skype/etc call for that one evening, so I can also explain what's what in the target.

* The code FPC generates is not position independent, but the QL startup code (by me) can relocate the binary after loading.

That is the same with the main C compiler we have, C68.

Ok, so keeping the relocations for job code should be possible, that answers some of my questions I had above, thanks.

QPC is some 1000 times faster than a QL and supports up to 256MB of RAM. Also it has limitles screen resolution, so unlike emulators like QemuLator that targets retro uses like games and hardware compatibility it's actually designed to be used as a desktop environment.

Yeah, so this definitely sounds like something the compiler could actually run on. I expect this can be realized sometime during 2021 for sure. I also wrote the most parts of the classic Amiga support under MorphOS (which is a native PowerPC AmigaOS clone/rewrite, but contains a 68k emulator so it can run classic Amiga binaries), so a much faster desktop environment being available on modern HW is great to hear, and certainly eases a lot of things.

5:20 in the morning? Up early or up late? I long for the times where I could still work all night on interesting stuff.

Both. That day I slept from early evening until early night, so I was up that time to work on things. Then I went back to have a nap again before my work day started. But yeah, I know the feeling.

If that is the dtoqlfp routine from the C68 source then this was Dave Walker's code and I'm 1000% sure he would be okay with it. Also, last year he gave me all his remaining sources and stuff and given me explicit permission to do with it as I wish. You certainly have my blessing.

Yes, it was. Thank you. As I wrote above, I will try to keep "3rd party" code imports out of the RTL, just to be 100% safe, but nothing speaks against including it into a QL support package then (which will be still part of the FPC code tree, just a bit separated).

[Chain-Q]

Phew. So... One more post. That was great feedback and help, thank you all, probably the best initial feedback of all the 68k platforms I ever worked on (which is most of them at this point), especially at such an early stage, and sorry I didn't get to reply everyone. I hope I didn't miss anything important. But reading all of it was quite motivating to get a bit more of this QL port thing moving even further forward.

About the OOP discussion: I'm personally torn between being a fan of OOP and hating it, I certainly don't like the way most people write OOP, even in Object Pascal, with the billion ton boiler plate and the object property setters/getters, but I see it as a very useful code organization tool for some patterns if kept under check and control. But to be honest, that's just the same with any methodology or even tool, a lot of people will just create a big mess of it anyway. Also, while FPC itself is mostly object oriented code, it only uses a subset of OOP features, so even we see the need for "keeping it under control". In any case, least in Pascal the barrier between OOP and non-OOP code is much lower than in say, the C/C++ language-pair, and you can still call OOP functions from structured code just fine, write structured helpers for OOP code, and vice-versa, and there's no need to obey slightly different rules for both.

Cheers!

[NormanDunbar]

So the code can be even shuffled around after loaded in memory between multiple runs?

No. Once the job is executed, it stays where it loaded to -- until it either removes itself, or, is forcibly removed from the system.

The dataspace is recorded in the job's file header. When executed, an area of RAM is allocated for the code plus an area of 'dataspace' size, for the job's stack and any storage it needs. The job can still allocate from the heap for large chunks of RAM, if it needs to.

HTH

Cheers,
Norm.

[tofro]

About the OOP discussion: I'm personally torn between being a fan of OOP and hating it, I certainly don't like the way most people write OOP, even in Object Pascal, with the billion ton boiler plate and the object property setters/getters, but I see it as a very useful code organization tool for some patterns if kept under check and control. But to be honest, that's just the same with any methodology or even tool, a lot of people will just create a big mess of it anyway. Also, while FPC itself is mostly object oriented code, it only uses a subset of OOP features, so even we see the need for "keeping it under control". In any case, least in Pascal the barrier between OOP and non-OOP code is much lower than in say, the C/C++ language-pair, and you can still call OOP functions from structured code just fine, write structured helpers for OOP code, and vice-versa, and there's no need to obey slightly different rules for both.

Cheers!

In case anyone wants to get rid of the prejudice "OOP == bloated", have a look at this presentation. The guy writes (and explains what he's doing) a game for a Commodore C64 in an hour.
I think he proves a point

Tobias

[mk79]

Hmm, so what is a "dataspace"? I imagine it's the QL terminology for the .bss section of the binary, no? As in, uninitialized (or initialized to zero after loading) data.

Yes, plus it houses the stack. Check out the QL bible http://www.dilwyn.me.uk/docs/manuals/QD ... 20v4.5.pdf chapter 3. There you see the standard job-header format and the diagram afterwards shows what registers are set up on entry:
a4 = data space (relative to a6)
a5 = command line string (relative to a6)
a6 = job base (job header). Basically a block of memory that contains the code from the file (.code + .data + .reloc) + the empty data space on top
a7 = top of data space

Now, I also imagine this entire approach collides with this data space allocation thing, so will have to be reworked then. Or?

Well, jobs are usually just called using the "EXEC" command (or "EX" for short if you have the absolutely essential TK2 toolkit or SMSQ/E), so for this thing to be really useful it must do without a basic loader. Which hopefully is not too difficult to pull off.

Cheers, Marcel