New Q60 Boards

[Peter]

<>
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?

I didn't say that. Requiring x86 / IA64 CPUs is not less restrictive than requiring >= 68020 though. (Didn't even say that that programs should do the latter.)

[tofro]

What I think makes sense (to me) is the following:

Sometimes, it's just moot to try and develop something that will run on an original QL with 68008 (and, maybe, even massively expanded memory): The poor 8-bit-CPU just doesn't have enough oomph to hit it, at least if you are going beyond some moderately complex tasks. If the task still fits the original QL, it makes sense to include it in the list of target machines. And, if you decide you want to target all possible QDOSMSQ machines, well that's the smallest common denominator and you need to restrict yourselves on the task, not the CPU.

On the other hand, there are really fast machines/emulators, like the Q40/60 or QPC (the latter being a total outlier, see below). If we're honest, programs won't become terribly more fast when we start to use 68020+ (or even better) instructions. There definitely are improvements over restricting yourselves to 68000 instructions, but not something like twice as fast (and that's the minimum you need to have to really "feel" an improvement beyond measuring). I'm talking about user experience, not bare numbers here, because that is what counts. If you want to write a demo for the Q60 or QPC, that's fine. But that will definitly not end up in a generally usable QDOSMSQ program.

And the third class, with the many new 68000-compatible machines we have, like the Q68 or QIMSI Gold (or even QXL and SuperGold Card-equipped QLs) - Those are all somewhat in the same class of SuperGold Card performance or thereabouts. That is, in principle, what I'm targeting. That means using only bare 68000 instructions and implementing stuff that these CPUs can manage.

Now for QPC2 - This is, as written above, an outlier with its massive performance on modern PCs which is far beyond what "real 68k" hardware will ever be able to achieve. To be honest, if you write something that will only ever run acceptably there - You're writing a demo. I'm probably guilty of that as well sometimes, because you simply might find that real hardware has its limits, and it's really nice to see 68k code do something which was far beyond our dreams 30 years ago, but these are not really usable QDOSSMSQ programs. (Again, my opinion).

So, I think, we should be trying to target the middle ground, the SGC "class". Hits the widest user base and doesn't (at least not completely) exclude the original black box.

[Peter]

What I think makes sense (to me) is the following: [...]

Fully agree to all points.

I would add that the "SGC class" has sufficient memory to include >= 68020 or FPU code for speed critical parts, while keeping the option to also execute on a 68000 with the same binary.

[Peter]

If we're honest, programs won't become terribly more fast when we start to use 68020+ (or even better) instructions.

My recent attempt to generate such code was triggered by a specialty. Which is the need for "demanding" code to test 68060 overclocking, including the EC version. The easy way to run something under Linux, requiring at least the LC verison, is blocked. In the worst case, I have to go bare metal IOT utilise GCC with -m68060, but that would probably cost lots of time. Such a test software could also be interesting for Derek, should he decide to use EC CPUs in the future.

Do you have any ideas what could be done, ideally an existing piece of software?

[tofro]

If we're honest, programs won't become terribly more fast when we start to use 68020+ (or even better) instructions.

My recent attempt to generate such code was triggered by a specialty. Which is the need for "demanding" code to test 68060 overclocking, including the EC version. The easy way to run something under Linux, requiring at least the LC verison, is blocked. In the worst case, I have to go bare metal IOT utilise GCC with -m68060, but that would probably cost lots of time. Such a test software could also be interesting for Derek, should he decide to use EC CPUs in the future.

Do you have any ideas what could be done, ideally an existing piece of software?

Well, GWASS will happily translate 68060 code. With a C compiler, you don't have really much influence to make the compiler choose '060 instructions anyways.

[Peter]

If we're honest, programs won't become terribly more fast when we start to use 68020+ (or even better) instructions.

My recent attempt to generate such code was triggered by a specialty. Which is the need for "demanding" code to test 68060 overclocking, including the EC version. The easy way to run something under Linux, requiring at least the LC verison, is blocked. In the worst case, I have to go bare metal IOT utilise GCC with -m68060, but that would probably cost lots of time. Such a test software could also be interesting for Derek, should he decide to use EC CPUs in the future.

Do you have any ideas what could be done, ideally an existing piece of software?

Well, GWASS will happily translate 68060 code. With a C compiler, you don't have really much influence to make the compiler choose '060 instructions anyways.

I appreciate that GWASS can do that in principle. But to write a test suite in assembler is far beyond my time budget. C compiled code for 68060 doesn't assemble with the existing QL toolchains. So there is no chance but to go bare metal?

[tofro]

My recent attempt to generate such code was triggered by a specialty. Which is the need for "demanding" code to test 68060 overclocking, including the EC version. The easy way to run something under Linux, requiring at least the LC verison, is blocked. In the worst case, I have to go bare metal IOT utilise GCC with -m68060, but that would probably cost lots of time. Such a test software could also be interesting for Derek, should he decide to use EC CPUs in the future.

Do you have any ideas what could be done, ideally an existing piece of software?

Well, GWASS will happily translate 68060 code. With a C compiler, you don't have really much influence to make the compiler choose '060 instructions anyways.

I appreciate that GWASS can do that in principle. But to write a test suite in assembler is far beyond my time budget. C compiled code for 68060 doesn't assemble with the existing QL toolchains. So there is no chance but to go bare metal?

Well, when using a C compiler, how would you even know your program is using any '060 instructions at all without a disassembler (and if not, how would that be a useful test, and then, how do you make the compiler actually decide to use '060 instructions)?

[XorA]

Well, GWASS will happily translate 68060 code. With a C compiler, you don't have really much influence to make the compiler choose '060 instructions anyways.

I appreciate that GWASS can do that in principle. But to write a test suite in assembler is far beyond my time budget. C compiled code for 68060 doesn't assemble with the existing QL toolchains. So there is no chance but to go bare metal?

Well, when using a C compiler, how would you even know your program is using any '060 instructions at all without a disassembler (and if not, how would that be a useful test, and then, how do you make the compiler actually decide to use '060 instructions)?

gcc -mcpu=68060

Its not rocket science

[tofro]

I appreciate that GWASS can do that in principle. But to write a test suite in assembler is far beyond my time budget. C compiled code for 68060 doesn't assemble with the existing QL toolchains. So there is no chance but to go bare metal?

Well, when using a C compiler, how would you even know your program is using any '060 instructions at all without a disassembler (and if not, how would that be a useful test, and then, how do you make the compiler actually decide to use '060 instructions)?

gcc -mcpu=68060

Its not rocket science

That makes the compiler use '060 instructions if it decides to do so. It doesn't force it, though. And, of course, you can't instruct it to use a specific instruction you want to test. You'll be able to test some instructions, but won't reach specific coverage.

I think one should go for mixed-mode programming: Have the test harness framework written in C (not using specific instructions, and compiled for generic m68k) and instruction test routines in assembly that test specific instructions.

[XorA]

Well, when using a C compiler, how would you even know your program is using any '060 instructions at all without a disassembler (and if not, how would that be a useful test, and then, how do you make the compiler actually decide to use '060 instructions)?

gcc -mcpu=68060

Its not rocket science

That makes the compiler use '060 instructions if it decides to do so. It doesn't force it, though. And, of course, you can't instruct it to use a specific instruction you want to test. You'll be able to test some instructions, but won't reach specific coverage.

I think one should go for mixed-mode programming: Have the test harness framework written in C (not using specific instructions, and compiled for generic m68k) and instruction test routines in assembly that test specific instructions.

It would however optimize the pipelines in the 68060 to fully load it, which is what I think Peter was wanting to test overclocking!