Turbo compiled Apps in ROM...

[martyn_hill]

Hi everyone, me again...

I recall reading that Turbo compiled apps can't be made to run (entirely) from EPROM due to a bit of space-saving optimisation in the Job initialisation routine that reclaims that space afterwards.

Is that still the case and, if so, is there value in researching whether this optimisation feature could be optionally switched-off at compile-time to make a ROMable executable?

[ql_freak]

IMHO Turbo does NOT produce reentrant code (Metacomco and C68 C also do not create reentrant Code; EJC based on the Lattice Compiler from Metacomco does).

So I see no use to have a Turbo compiled program in an EPROM. Qliberator programs are reentrant and IMHO ROMable.

[martyn_hill]

Thanks Peter - that matches what I thought

[tofro]

First and foremost: I don't think anything not written in Assembly belongs into a ROM

(Reasons: Code size considering the scarce ROM space available, overhead, problems creating binary structures like ROM headers, for example, and a lot of required mystical command switches when building your program)

@Peter: Both Metacomco C and C68 actually can produce reentrant code - Just not by default. You need to tell them to create position-independent code and you need to provide your own libraries and startup code (or be very, very careful what you link to your program).

C68 seems to have problems when trying to create PIC programs - It tends to crash with an internal error. I have, however, found recently that fiddling around with your source code can make it work. (If the first function called from main() is located in a library instead of an object file, all seems to be fine - absolutely no idea why)

C68 wants to see something like "CFLAGS= -O -extension=yes -datamodel=small -codemodel=small -regdata=a5 -regframe=a6" to create reentrant programs.

Metacomco C wants "CFLAGS=-b -r -n -ccmsw -dC68"

And for both you need to make sure you got the proper SECTIONs defined in the linker control file. You'll also need to provide your own startup code in assembly (which is relatively simple). The startup code that comes with the compilers will try to relocate the program - which is neither needed nor useful, because it's PIC now.

[martyn_hill]

Hi Toby!

First and foremost: I don't think anything not written in Assembly belongs into a ROM

A good religious argument that we should take-up over a beer

(Reasons: Code size considering the scarce ROM space available, overhead, problems creating binary structures like ROM headers, for example, and a lot of required mystical command switches when building your program)

For sure, the usual 16KB ROM slot is insufficient for any really useful compiled app, but your 128kb QL user, with say, a 64KB EEPROM mapped into the top 128KB of our beautifully linear, but meagre 1MB addressable space could benefit from a cut-down version of for example, Andrei's brilliant QLC File Manager being available without taking up significant transient prog space.

Finding that Turbo does a better job in terms of compiled execution speed on a BBQL over QLib, it felt worth exploring

[Wicksy]

There's a lot of new QL user's appearing over this last year with just a base 128k QL, so that point is very valid (me included).
Am hopeful of having a 128k eprom board made, early days but I hope to have a yeah or no in a month. I'd like it to be available to more than just me, but that wouldn't be my decision.

[ql_freak]

First and foremost: I don't think anything not written in Assembly belongs into a ROM :)

Of course not an executable program. But you can write functions with Lattice- or C68-C, which you call from Assembler. They produce, especially when optimised, quite good code, and it's a lot easier to write code in C than all in assembler.

[Martin_Head]

For sure, the usual 16KB ROM slot is insufficient for any really useful compiled app, but your 128kb QL user, with say, a 64KB EEPROM mapped into the top 128KB of our beautifully linear, but meagre 1MB addressable space could benefit from a cut-down version of for example, Andrei's brilliant QLC File Manager being available without taking up significant transient prog space.

Finding that Turbo does a better job in terms of compiled execution speed on a BBQL over QLib, it felt worth exploring

I can't immediately think of any reason why you could not put the Turbo toolkit, and/or the Qlib runtimes into a ROM. That would free up some space on a base QL

[martyn_hill]

Hi Martin!

Yes, indeed, the respective Toolkits, along even with PE components work well from ROM (I have 128KB non-volatile SRAM in a couple of my QLs that I use as ROM), freeing-up valuable RAM in the process.

If a smallish (30-40kB) compiled utility app or two could also be squished into ROM as well, it could offer a cheapish way for users of the basic machine to get more use out of it. The OPD series proved how effectively ROM could.be used for apps (albeit, pure MC apps...)

QLib is brilliant and does a grand job of increasing performance out of SuperBASIC, but it still lags behind Turbo compiled apps in my experience as far as run-speed is concerned - the other bottleneck in the original QL design...

I'll dig a bit deeper to see exactly what Turbo'd apps do that currently renders them non-rentrant today... Might be a dead-end, but worth a look...

[RalfR]

Jochen Merz's "Thing and Eprom Manager" has a keyword to check, if a self-made ROM is really romable, however, I don't know to what extent he checks this.