New Q60 Boards

[pjw]

<>
Actually, I don't think this is a problem (rather some sort of advantage or case of forced self-restraint): I don't think we want the world of QL software which is small enough already, further sub-divided in programs that can only run on certain CPUs and FPUs.

<clap><clap><clap><clap><clap>..

[Derek_Stewart]

I did not mean the compilation specific of 68020,040,060.

It would seem that certain C68 source code compiled with QDOS-GCC, for example micro-emacs has an update cross compiled with GCC, is reputed to increase the speed by 30%

Now I only read this, so can not verify if this is correct.

Maybe I am wrong to believe what is written.

[tofro]

I did not mean the compilation specific of 68020,040,060.

It would seem that certain C68 source code compiled with QDOS-GCC, for example micro-emacs has an update cross compiled with GCC, is reputed to increase the speed by 30%

Now I only read this, so can not verify if this is correct.

Maybe I am wrong to believe what is written.

Actually, that reputation must be taken with one or more grains of salt. Yes, some programs are really like 30% faster when compiled with GCC. But some other programs are even slower than C68 code, so mileage tends to vary. Unfortunately, GCCs 68k support has never been comparable to what it can do for the x86 - where it is really able to compete with good assembly programmers - in creating m68k code, its by far not as good.

[Derek_Stewart]

I did not mean the compilation specific of 68020,040,060.

It would seem that certain C68 source code compiled with QDOS-GCC, for example micro-emacs has an update cross compiled with GCC, is reputed to increase the speed by 30%

Now I only read this, so can not verify if this is correct.

Maybe I am wrong to believe what is written.

Actually, that reputation must be taken with one or more grains of salt. Yes, some programs are really like 30% faster when compiled with GCC. But some other programs are even slower than C68 code, so mileage tends to vary. Unfortunately, GCCs 68k support has never been comparable to what it can do for the x86 - where it is really able to compete with good assembly programmers - in creating m68k code, its by far not as good.

I am taking about C compiled code.

Assembley language programs are is always going be faster, smaller.

[tofro]

I did not mean the compilation specific of 68020,040,060.

It would seem that certain C68 source code compiled with QDOS-GCC, for example micro-emacs has an update cross compiled with GCC, is reputed to increase the speed by 30%

Now I only read this, so can not verify if this is correct.

Maybe I am wrong to believe what is written.

Actually, that reputation must be taken with one or more grains of salt. Yes, some programs are really like 30% faster when compiled with GCC. But some other programs are even slower than C68 code, so mileage tends to vary. Unfortunately, GCCs 68k support has never been comparable to what it can do for the x86 - where it is really able to compete with good assembly programmers - in creating m68k code, its by far not as good.

I am taking about C compiled code.

Assembley language programs are is always going be faster, smaller.

On a modern x86 CPU, you'll be having a hard time proving that.

[XorA]

On a modern x86 CPU, you'll be having a hard time proving that.

yeah I would love to see a human that can schedule code efficiantly on 80+ cores with 10+ execution units each.

[Derek_Stewart]

getting a bit off topic.

When I expect a system that can do this?

[Peter]

Actually, I don't think this is a problem (rather some sort of advantage or case of forced self-restraint): I don't think we want the world of QL software which is small enough already, further sub-divided in programs that can only run on certain CPUs and FPUs.

I do not intend sub-dividing QL software. My recent trigger for looking at >= 68020 GCC code generation was to possibly port C code that can generate high CPU load for '060 overclocking stability tests. I know by experience that plain 68000 code is insufficient for that purpose. If a new '060 machine is designed, it must be stable for all kinds of code.

Furthermore, a program can detect the CPU type and select accordingly, so it runs everywhere. The possibily to at least optimize portions of code is still nice to have.

There are programs which are only usable with emulators running on x86 / IA64 CPUs. Because their speed requirements have by far left the 68K range of machines. No forced self-restraint there.

[Peter]

Actually, that reputation must be taken with one or more grains of salt. Yes, some programs are really like 30% faster when compiled with GCC. But some other programs are even slower than C68 code, so mileage tends to vary.

I tend to doubt the latter, if the most suitable code generation options are selected. At least such cases sound very exotic. I have compiled tons of C code with both compilers and QDOS-GCC was always faster.

Unfortunately, GCCs 68k support has never been comparable to what it can do for the x86 - where it is really able to compete with good assembly programmers - in creating m68k code, its by far not as good.

In terms of speed, QDOS-GCC is still surprisingly competitive to assembly programming. I've seen it outperform assembler code, where I'd never believed it could.

[pjw]

<>
There are programs which are only usable with emulators running on x86 / IA64 CPUs. Because their speed requirements have by far left the 68K range of machines. No forced self-restraint there.

So one should only produce programs that dont need speed because the "real" hardware (real or emulated "real") cant do it justice? That seems rather an odd restraint to subject oneself to (IMHO).

Some might suggest that the only "true QL patriots" are those who restrict themselves to the unadulterated QL 128k. Perhaps they are right?

Anyone reading this has a PC of some description, and anyone with a PC can run QPC2 or almost any of the other free emulators - if they want to. So really, there is no externally imposed restriction. (Q-emulator is not wholly free, but well worthy the small price of the full version.)

That being said, anyone producing QL hardware or software should strive for compatibility across platforms and systems as far as possible, and not unnecessarily exclude either higher-spec or lower-spec systems.

And clearly, none of that should stop anyone from taking advantage of new facilities where available, even when that leaves some systems that dont support them, behind. Otherwise whats the point of progressing with anything?