Starting with C on the QL
Starting with C on the QL
After years of 'playing' with C on RISC OS using GCC, I've decided to have a play with C on the QL.
Can anyone point me in the right direction as to which compiler I should use?
I see there are quite a few available.
Any feedback would be greatly appreciated.
Can anyone point me in the right direction as to which compiler I should use?
I see there are quite a few available.
Any feedback would be greatly appreciated.
--
If vanpeebles parps in the woods and there is nobody around, does it make a sound?
If vanpeebles parps in the woods and there is nobody around, does it make a sound?
-
- Font of All Knowledge
- Posts: 3970
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Starting with C on the QL
Hi Rob,
The best C compiler for the QL is C68, which is an ANSI C compatible compiler.
C68 is available on Dilwyn's web site and has many ported C programmes from Linux/UNIX.
QPTR programmes can be wriiten with Tony Tebby QPTR C Libraries.
It is worth a look.
The best C compiler for the QL is C68, which is an ANSI C compatible compiler.
C68 is available on Dilwyn's web site and has many ported C programmes from Linux/UNIX.
QPTR programmes can be wriiten with Tony Tebby QPTR C Libraries.
It is worth a look.
Regards,
Derek
Derek
Re: Starting with C on the QL
Thank you for the speedy reply!
I'll take a look at C68 tonight.
I'll take a look at C68 tonight.
--
If vanpeebles parps in the woods and there is nobody around, does it make a sound?
If vanpeebles parps in the woods and there is nobody around, does it make a sound?
-
- Font of All Knowledge
- Posts: 3970
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Starting with C on the QL
Hi Rob,
I do not work now, after redundancy/early retirement... so nothing to do except learn how to programme correctly.
I ported over txtElite from the GCC Linux version, which when removal of the GETS() command for user input compiled on Linux and C68, with only a warning on C68 about a SQRT() statement having its prototype changed. Probably changing Double to Integer.
The programme compiled directly on Linux GCC and C68 once all ANSI C statement errors were correctly.
Which is quite a neat thing, so most Linux ANSI C source code,could be ported to the QL.... in theory that is.
I do not work now, after redundancy/early retirement... so nothing to do except learn how to programme correctly.
I ported over txtElite from the GCC Linux version, which when removal of the GETS() command for user input compiled on Linux and C68, with only a warning on C68 about a SQRT() statement having its prototype changed. Probably changing Double to Integer.
The programme compiled directly on Linux GCC and C68 once all ANSI C statement errors were correctly.
Which is quite a neat thing, so most Linux ANSI C source code,could be ported to the QL.... in theory that is.
Regards,
Derek
Derek
- vanpeebles
- Commissario Pebbli
- Posts: 2821
- Joined: Sat Nov 20, 2010 7:13 pm
- Location: North East UK
Re: Starting with C on the QL
I just read about txtElite in the new quanta mag. I'm looking forward to giving it a go
Re: Starting with C on the QL
Purism aside, from a practical point of view it'd be great to have some modern C cross compiler for creating QL software. I did a bit of hacking with vbcc and got it to work (at least a proof of concept), but making QL a real supported platform would require a lot more work.
-
- Font of All Knowledge
- Posts: 3970
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Starting with C on the QL
Hi Marq,
XTC was developed to use C68 Libraries on Linux and DOS, this should be available.
Most of Joanthan Hudson's programmes were cross compiled with XTC.
The executable has been reported to give a 30% speed increase. I have not used XTC before, but I will see if I can get a hold of the package.
XTC was developed to use C68 Libraries on Linux and DOS, this should be available.
Most of Joanthan Hudson's programmes were cross compiled with XTC.
The executable has been reported to give a 30% speed increase. I have not used XTC before, but I will see if I can get a hold of the package.
Regards,
Derek
Derek
Re: Starting with C on the QL
I have xtc68 for DOS (runs well in a Windows 7 CMD window) found somewhere on my hard disk. As far as I can see, it's the "normal" C68 compiler and tools modified to run on DOS - Can't really see why there should be a speed increase in the resulting binaries, though.
There was, if I remember right, a gcc port to QDOS in the late 90ies around (Ported by Franz Herrman??) that was said to produce considerably faster binaries than C68. This could only be run as a cross-compiler from Linux, if I remember right. Unfortunately I do not have a copy.
Regards,
Tobias
There was, if I remember right, a gcc port to QDOS in the late 90ies around (Ported by Franz Herrman??) that was said to produce considerably faster binaries than C68. This could only be run as a cross-compiler from Linux, if I remember right. Unfortunately I do not have a copy.
Regards,
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Starting with C on the QL
I checked that GCC out last year, but it's so old that it can't even be compiled anymore GCC is a complex beast anyway, so in that sense VBCC would be the easier route. I got it working with a static address, but as far as I've understood, well-behaving QL binaries should be position independent?
Re: Starting with C on the QL
Yes, they should - In principle. But that also limits their possible size significantly as most of the register-relative addressing only works +-32k on a plain 68000 - 68020+ would be different.Marq wrote: but as far as I've understood, well-behaving QL binaries should be position independent?
C68 works around this by bringing its own relocation function in its C startup code. The linker builds a relocation table that is used by the C startup code to relocate long addresses according to the code load address. This makes all C68 programs "impure" in a pure Tony Tebby sense because you can't just simply re-use the code in RAM for more than one job running concurrently (because in a pure sense relocation would be considered self-modifying code which is a no-no in the TT world). Apparently, programs that need to jump farther than 32k weren't really considered useful in the QL's early days.
BTW, the "purity" challenge for QL programs wasn't built into the original OS - That only came up with Hotkey system 2 and QRAM that actually introduced the first mechanisms to run several jobs on the same piece of code.
Regards,
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO