New ppc board by Acube/A-Eon: A1222 "Tabor"

[itix]

In reality if Hyperion and co cant get AmigaOS 4.x working with an acceptable performance with the majority of existing software do you think that the Tabor will go into production for the AmigaOS 4.x market ?

Why not? ;-) just think what Commodore did ;-)

[itix]

I'm talking about whatever FPU emulation is currently available (under Linux), using whatever benchmarks are available. Sure, people can argue ad nauseum about whether benchmark results are meaningful, but having any data would be better than making big claims about performance based on assumptions.

Of course the emulation is going to have overhead; I'd like to know how it actually performs.

I am very surprised if Linux had FPU emulation there...

[itix]

im pretty sure fpus are totally overrated. it just a fancy of chip designers. all the code is equally well executed in software. same for all other sorts of hardware acceleration btw.

I would say FPUs (floating points in general) are underused on Amiga. I was portit one my app from MorphOS to AmigaOS 3 and I really had problem what FPU model I should target at. There are many options (68881, 68882, 68040, 68060 and handful of math libraries) you have to choose from. Had I written the software for the 68k target first I would have used integers only.

[itix]

The 68881 and 68882 are essentially the same target even if it is possible to specify one or the other. Vbcc will generate the exact same code with 68881 or 68882 specified. The 68040 and 68060 FPU are similar but the 68040 made the biggest blunder in processor history by leaving out the common FINT/FINTRZ instruction which the 68060 fixed. There are big differences in the instruction timings and exception handling between the 68040 and 68060. Code compiled for the 68040 should work on the 68060 and vise versa but with reduced performance. Code compiled for the 6888x will work on the 68040 and 68060 but with further reduced performance (from lots of trapped instructions). Code compiled for the 68040 or 68060 may not work for the 6888x (GCC=no, vbcc=yes).

My programs was not using floats much. I just used floats for convenience. I think I tried using math libs first but stumbled on some issue why I couldn't use it. In the end I used 68882 target although it really requires fast 68060 (for other reasons than floats).

Heavy use floating point applications will benefit from multiple executables for all 68k CPU+FPU processors or 6888x and 68060 (telling 68040 users to use OxyPatcher/CyberPatcher/MuRedox). Light use 68k floating point can target the IEEE math libraries, 6888x-68060 or 6888x. I compiled vbcc using vbcc with both the IEEE libraries and direct 68060 FPU support and found no significant difference in speed of my test compiles (to my surprise). Testing will give a good indication of what is best for a particular application.

Is VBCC using floating point much? It is supposed to run on systems without FPU...

[itix]

What does that mean? Floats have a very specific use, which is to trade accuracy for a greater range (they effectively are lossy compression).

I had audio settings (can't remember what, this was 10 years ago) where accepted range was from 0.0 to 1.0. Obviously, I could have used integers, but when doing arithmetic you must remember scale factor and be careful to not run out of integer range.

With floats it is just easier to code and the precision is good enough.

[itix]

Sure in your example you can justify it because you are unlikely to get any bug reports if the volume is slightly wrong, although you shouldn't compile it to require an fpu as that is putting an unnecessary requirement.

Why not? If I have used floats to save some typing and it works then why on earth I should care if it won't work on some non-FPU machine? It is same reason why I don't support palette based displays. I could do that but I have other tasks to do.

Anyway, just checked what my floats do. It is for real time effects in audio playback (it is a CD player,, so it is useless today).

[itix]

Why not? If I have used floats to save some typing and it works then why on earth I should care if it won't work on some non-FPU machine?

Why would you bother writing software if you don't care if it will work or not?

For fun. I am not a slave.

[itix]

Better code density (smaller code size) is an advantage with a memory extension like XMS for the PC. How many Amiga 68k users complain about 128MB of memory not being enough compared to Amiga PPC users complaining about 512MB not being enough? I wonder how much memory the Tabor FPU trapping support code will take up?

In modern computing code density and code size have very little to do with memory requirements. PPC code requires 50% more space (versus 68k code) but we are still talking few hundred kilobytes.

It is the data that counts.

[itix]

Ridiculous thing to say, modern memory usage is all about data, code is like 1% of it.

eg SketchBlock is 3.5MB unstripped (plus some small libraries and filters) but as I'm working in quad float pixels I can max out on 1.5Gb of free ram when dealing with modern digital camera images.

Unstripped exec just contains debug information (function names etc.). The instruction section is much much smaller than that...

[itix]

It depends on the programs (streaming data needs little memory and no DCache for example) and sometimes 68k "data" is smaller also because of less alignment restrictions. Code density is more important to processor performance where the 68k can have 40%-50% more code in the ICache and to bandwidths which allow code to be transferred 40%-50% faster.

It doesnt really matter when my PPC is still much faster at executing code (68k or PPC) than a real 68060.

DCaches are rarely larger than ICaches despite some programs using much more data. Memory is cheap now days but even tens of MBs are important to the AmigaOS where 64 bit pointers will break compatibility.

With 68k code you dont save tens of MBs. You could port the latest OWB to 68k and it still would not run well with 128 MB. 68060 is still too slow to run the latest webkit engine, 128 MB is still too little to run the latest webkit engine.

Code density is important enough that most modern 32 bit mobile and embedded devices use ARM with Thumb 2 or Android's Dalvik byte code which have good but inferior code density to the 68k. IMO, it makes sense for the Amiga to leverage all the advantages of compatibility and a small footprint with the 68k using 32 bit for the low end.

But the small footprint is just due to lack of features. Lack of Unicode support, no built-in USB stack, rudimentary GUI toolkit (unless you install MUI but then it is not small footprint anymore), lack of text antialiasing and truetype font support, simple 4 colour icons (versus true color PNG icons) i.e. it is stuck in 90s.

The high end could break compatibility converting to 64 bit pointers while adding SMP and using a sandbox for AmigaOS 3 and 4 compatibility but I don't think there is enough market for it currently and especially with the price/performance and future prospects of PPC. The same technology used to make an enhanced 68k CPU (and learn from it) could be used to make a new 68k like 64 bit SuperCISC ISA and CPU design (if necessary) which is better than x86_64 (an average ISA at best while the CISC advantages giving the most powerful consumer processors in the world are continuously overlooked). It would require some investment but at least the Amiga could control its destiny, standardize and innovate instead of being dependent on the last small customer PPC manufacturer and aging embedded designs.

I dont see point in new super 68k but I get your idea. The PPC is obviously stuck in year 2005 forever.

[itix]

Stupid question: is it possible to let the second core stand in as an FPU?

No. It would be very very slow.

[itix]

Even as a dedicated software emulation core?

The first core can't proceed until FPU instruction emulation is completed. Thus emulating FPU on 2nd core would halt the first core.