@Tomppeli

Yeah, but that only works when the SW in question is still activly supported to the point of the author being bothered about supplying different versions (or release sources).

Also back in the day, a 040/060 would still run most SW compiled for 020/881 without problems and it would run all SW compiled for 68000/020/030 (without FPU).

As such a developer could do basic testing of all version with just one piece of HW, while SW compiled for Tabor will fail on all other PPCs and the otherway round.

Unless the devloper creates a version that does not use and FPU probraly seriously crippling performance all over the board.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Tomppeli

Quote:

So making multiple versions of software is a no go somehow suddenly ?! We had separate versions of a piece of software for 68000, 68020, 68030, 68040 and 68060 in the same archive in the past. Like you have now non-altivec and altivec versions of, for example, MPlayer and ffmpeg.

That is entirely different issue. 68000 versions run everywhere, on every CPU. 68060 lacks quite many instructions but they are still emulated so you can run vanilla 68000 version on it.

Same with Altivec. Non-Altivec versions still run on G4 and PA6T. It is just that with Altivec version could run faster on that hardware.

With Tabor it is different. Vanilla builds are not guaranteed to run. Someone must build special Tabor build. That is, someone must rework his makefile to build two different builds, someone must rework his installer scripts and sometimes there is no this mysterious "someone" to do this job anymore.

Please keep in mind that in the past separate versions for 000/020/040/060 were not so common. They were limited to certain key libraries and applications to get maximum throughput (jpeg decoders, archivers etc) while majority of Amiga software was done "one build for all" style. It is practical since it saves developer's precious time.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Quote:

Vanilla builds are not guaranteed to run.

I thought concerns were not "applications will not run", but "applications will run slooooowly".

@Tomppeli
And how many people do you think will be willing to do that? Don't pretend it's still the 90s. The community shrunk, and become fractured. There isn't an abundance of OS developers to make Tabor-specific versions.

Last edited by BSzili on 20-Mar-2016 at 07:14 PM.

_________________
This is just like television, only you can see much further.

@pavlor

Quote:

I thought concerns were not "applications will not run", but "applications will run slooooowly".

I didnt think so because Rob wrote in the message #1:

Quote:

I've seen plenty of comments on why software using unsupported instructions would either fail or be too slow but I've yet to see anyone try and build up a picture of what impact that would have in the real world. If we take the worst case scenario, where software using those instructions simply fails, what software would we be left with and what would have to be fixed to make the system attractive to those interested in using it to run OS4.

If you go emulation route then it is only matter of money. Get someone to write PPC JIT compiler to translate PPC programs to "Tabor native".

Something like Petunia.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Read post 40 in this very thread...

@pavlor

Yeah, but one could do all these with "no problem there" on an rPI or even something like an AMD K2 ......

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Spectre660

Only Amiga makes it possible.

@Tomppeli

Quote:

So making multiple versions of software is a no go somehow suddenly ?! We had separate versions of a piece of software for 68000, 68020, 68030, 68040 and 68060 in the same archive in the past. Like you have now non-altivec and altivec versions of, for example, MPlayer and ffmpeg.

the library versions hell. one of the worst nigthmares ive faced with amigas. and you think it is a good solution to follow into the footsteps today? whoa!

@All

I am very skeptical about the choice of the cpu, I don' t see the benefits to OS4 but only drawbacks.

Is this a bad hardware design or? Am I wrong?

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

>Is this a bad hardware design or?

P1022 was available when T1022 was not...
P1022 is OK, except the "FPU".

I'm looking forward to SAM440ep upgrade and wait to see Tabor in real AOS4 use before making decision.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Massi

Quote:

I don' t see the benefits to OS4 but only drawbacks.

Only benefit could be low price.

Quote:

Is this a bad hardware design or? Am I wrong?

Tabor is nice design, but choice of SoC is really weird. So you are right.

@Spectre660

Post #40
"Test post from Tabor using Qupzilla webbrowser runing under Ubuntu Mate 16.04 regular powerpc32 version. So everything done using emulated floating point."

Sorry, but I have forgot:
-does that mean FPU JIT emulation or vanilla FPU emulation?
-so, does it do FPU to SPE JIT magic

Last edited by KimmoK on 21-Mar-2016 at 03:35 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

This means some PowerPC32 Linux applications work OK with "vanilla FPU emulation".

Quote:

so, does it do FPU to SPE JIT magic

There is nothing such yet. We don´t even know, if this is possible.

@Massi

Quote:

Is this a bad hardware design or? Am I wrong?

it seems, it is rather wrong hardware for wrong purpose, if the purpose is running os4 that is. but this seems to have always been characteristics with hardware declared to be dedicated to os4. so the design choices here seem to perfectly fit the pattern.

Tabor's processor is a dual core processor and AmigaOS 4.1 can only use one core. Couldn't the other core be used entierly for FPU calculations? Wouldn't that mean a fast FPU?

@Niolator

AmigaOS supports more than one core?

@Niolator

No.

@OlafS25

No.

@Niolator

No that's not how the FPU works, the FPU is not really running in parallel to CPU, it’s a extension of instruction set only (aka more instructions).

A program contains a mix of FPU instruction, integer instruction, and AltiVec instructions (if you have that).

And they are executed in serial, (at least from a developers point of view), next instruction can't execute before previous is completed. (More or less)

So what your suggestion is that the program on Core1 has to wait for Core2 to emulate FPU instruction, and possibly need to sync up data cache, so this is really bad idea.

Last edited by NutsAboutAmiga on 21-Mar-2016 at 04:41 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Niolator

The FPU is responsible for "point numbers", while standard CPU instructions is integer or Natural numbers.

FPU extends the CPU, allows you to work with number like
10 power 10000, or fraction of number 1/3 ~ 0.33333333333333333333.
This gives the CPU preseason.

Last edited by NutsAboutAmiga on 21-Mar-2016 at 05:12 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS