http://www.amiga.org/forums/showpost.php?p=797990&postcount=212

Quote:

Quote: Originally Posted by kolla What prevents binaries from asking the OS about the abilities of the hardware, and run code accordingly? I mean, other operating systems manage to have "fat" binaries that contain entirely different architectures, but on Amiga it is not even possible to have one binary for variations within one architecture. :Quote This is already done in various programs for altivec/non-altivec code. The W3D_SI driver, for example, will use altivec on hardware that has it, and non-altivec code on machines that don't. The graphics library goes one step further and has copy routines that are optimized for specific processors (incl. using DMA on certain platforms). IIRC, MiniGL has a few altivec routines as well. The examples above are a bit different from simply having a fat binary with completely different compiles sitting there side-by-side. Instead, the developer himself/herself compiles different versions of just the parts that matter. I personally prefer that approach, as the sections of a program that actually benefit from altivec/SPE/whatever is usually limited. Hans .

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@pavlor

Ah, but by the power vested in him by the great Intel, he can conclude whatever he wants, and he also HAS the right to post one in three posts in any thread that could possibly be considered good news for AOS4. It's just one of those things. Betweem them, cdimauro, OlafS25 and wawa can turn any rumour into a fact in less time than it would have taken Goebbels to say "the polish are committing atrocities against germans in Danzig". No qualitative comparison intended.

In a serious note: All respect to A-Eon and ACube, but I fear they've been conned on this one. It's never too late to turn around, guys. Replacing the P1022 with the T1022 is not a direct drop in replacement, but it can probably be done in less than two months and will not bring ANY incompatibility issues as it's a core that is supported anyway.

I'm all in favour of instant gratification, as long as the instant doesn't come in the way of the gratification. Or said in a different manner: instant torment is not as good as delayed gratification.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

Yesterday evening I watched the speech held by Trevor at Amiwest 2015. He talked about this new board, the Tabor. He put weight on the fact that the board will be low cost. This means that it will be the cheap entry-level alternative that many have been asking for in the past. I think that's very good news! A-EON has ordered 1000 (!) of these boards, so it'll be cheaper than the SAM's in the past, don't you think?

_________________
Old School Game Blog
Gaming on AmigaOS 4
Void - Amiga Demo Group

@AmigaOldskooler

Quote:

so it'll be cheaper than the SAM's in the past, don't you think?

I hope so. Low price is probably only way to sell this board to more users.

@olegil

Playing Nazi card is always classy move.... /s

@olegil

Quote:

Ah, but by the power vested in him by the great Intel, he can conclude whatever he wants, and he also HAS the right to post one in three posts in any thread that could possibly be considered good news for AOS4. It's just one of those things. Betweem them, cdimauro, OlafS25 and wawa can turn any rumour into a fact in less time than it would have taken Goebbels to say "the polish are committing atrocities against germans in Danzig". No qualitative comparison intended.

i dont know where you are from, but im polish born in gdansk, and likely i know more about the subject to find it rather inappropriate to be compared to national socialist propaganda ministers and the like. another they you might be implying us three are planning a genocide on remaining os4 users i take it.

Quote:

In a serious note: All respect to A-Eon and ACube, but I fear they've been conned on this one. It's never too late to turn around, guys. Replacing the P1022 with the T1022 is not a direct drop in replacement, but it can probably be done in less than two months and will not bring ANY incompatibility issues as it's a core that is supported anyway.

and all above just to conclude the same whatever some of us and others have pointed out in this thread and elsewhere, namely that the cpu choice might not be the best, however trying to look as if you were distancing yourself form us, who apparently brought that up. extending on your sorts of comparisons, it reminds me of people, who say "we have nothing against foreigners, but we understand those who have."

Last edited by wawa on 24-Oct-2015 at 01:29 PM.

@olegil

you are so cool... our master of intelligence

I must bow deeply to your far superior intelligency

I think your words speak for yourself

@pavlor

Quote:

I thought your own comments in this thread proved we know nothing about performance of FPU emulation in hardware.

Actually the figures on the delays inherent in trapping were, as I put it, compelling.

And after thinking about it last night, if there is instruction/opcode overlap, won't those instructions start to execute before failing?

We don't know how much of a performance hit there will be, but that's far from "we know nothing about performance of FPU emulation in hardware".

Because this isn't completely a hardware solution (that would be as simple as implementing a cpu with a standard fpu), this involves using software to intercept these illegal opcodes, then translate them into spe instructions, then hardware can be used to execute the translated instructions.

So we DO know there WILL be added overhead.

@olegil

Quote:

Replacing the P1022 with the T1022 is not a direct drop in replacement, but it can probably be done in less

BUT if they already have 1000 e500v2 CPUs purchased and ready for production?
Design and production have a kind of inertia.

@AmigaOldskooler

Quote:

...Trevor at Amiwest 2015. He talked about this new board, the Tabor. He put weight on the fact that the board will be low cost. This means that it will be the cheap entry-level alternative that many have been asking for in the past. I think that's very good news! A-EON has ordered 1000 (!) of these boards, so it'll be cheaper than the SAM's in the past, don't you think?

Ah, low cost has some advantages.
But knowing that the cost of equipping a similar board with a T10XX processor would only add $10 to the price (less than moving from an e500v2 cored processor to an e500mc cored processor)?
That would eat at me over time.
Which is the primary reason I can't consider Tabor.

Last edited by iggy on 24-Oct-2015 at 03:26 PM.
Last edited by iggy on 24-Oct-2015 at 03:21 PM.

Is it so difficult to understand that when development of Tabor begun the T1xxx processor didn't exist again?

Did A-Eon have to trash all the work and the money they spent in order to start a new project based on T1xxx cpu?

Sure, now it could (how easy is playing with others' money) but the new Tabor probably would not be ready before 2 years...

@iggy

Quote:

We don't know how much of a performance hit there will be

Right.

Quote:

So we DO know there WILL be added overhead.

Of course. But by your own words: We don't know how much of a performance hit there will be

And this is question we all are looking answer for.

Quote:

But knowing that the cost of equipping a similar board with a T10XX processor would only add $10 to the price (less than moving from an e500v2 cored processor to an e500mc cored processor)?

T10XX SoCs are cheaper than P1022... However, as NRE costs for P1022 board are already paid, A-Eon has no other choice than continue with Tabor project.

@pavlor

Quote:

pavlor wrote: @cdimauro Quote: but it's a clear lie I thought your own comments in this thread proved we know nothing about performance of FPU emulation in hardware.

I reported some data from the e500v2 reference manual, which clearly show how long it takes to just execute the FIRST instruction of the trap handler. In the best case it takes 10 cycles, and the SPE unit can execute up to 20 (TWENTY) floating point instructions in such time.

This is a FACT, but you're free to take such manual and show me that I'm wrong, eh!

Last but not least, this is just the BEST case (worst is 8+7 = 15 cycles. Again: take a look at the manual) and the first instruction. Then you have to add all required instructions to:
- get the offending opcode;
- decode it;
- execute the proper code to emulate its behavior;
- switch back from the trap handler to the normal execution flow.
So, more, and more cycles needed...

The LAME example showed that, without using the SPE unit, the execution was 96 TIMES slower than the native code.

If you expect that using the SPE unit makes miracles, well, you're an incurable optimistic. The situation will change, of course, but not of an order of magnitude.

But I've problem here: let's wait and see when OS4 will run on the Tabor board.


@olegil

Quote:

olegil wrote: @pavlor Ah, but by the power vested in him by the great Intel, he can conclude whatever he wants, and he also HAS the right to post one in three posts in any thread that could possibly be considered good news for AOS4. It's just one of those things.

The usual Ad hominem attack from the usual fanboy which cannot accept the reality.

As I said, I've reported data from the e500v2 manual: feel free to prove that I was wrong.
Quote:

Betweem them, cdimauro, OlafS25 and wawa can turn any rumour into a fact in less time than it would have taken Goebbels to say "the polish are committing atrocities against germans in Danzig". No qualitative comparison intended.

What pathetic behavior. You're so desperate by the fact that you cannot rebut what I've stated, that the only way that you find is to resort to such squalid story...


@Rose

Quote:

Rose wrote: @olegil Playing Nazi card is always classy move.... /s

*


@iggy

Quote:

iggy wrote: @pavlor And after thinking about it last night, if there is instruction/opcode overlap, won't those instructions start to execute before failing?

In this case the big problem is that those instructions will not fail: they just execute, but doing completely different things.

I expect that the program will fail due to the consequences of this erratic computations, but who knows if and when...

@cdimauro

Quote:

But I've problem here: let's wait and see when OS4 will run on the Tabor board.

At least something we can both agree upon.

@cdimauro

Quote:

the big problem is that those instructions will not fail: they just execute, but doing completely different things. I expect that the program will fail due to the consequences of this erratic computations

Well, that could really have an ugly effect.

BTW - Is anyone aware of how long Tabor has been available to developers?

I can't comment on the info I received today (because I don't want to piss off a friend), but its a LOT longer than you would think.

Which makes you wonder why Spectre660 just got his, and why the Hyperion developers don't have a software solution for hardware that apparently exists.

Quote:

The usual Ad hominem attack from the usual fanboy which cannot accept the reality.

Yeah, I've received a lot of flames over this myself.

And worse yet, as person that has been a big advocate of both A-eon and Varisys' work, I can't help but think wtf?

Yes the design work necessary to change the cpu on this board could have been started almost two years ago.

But what if production was close when that decision needed to be made?

@iggy

Quote:

BTW - Is anyone aware of how long Tabor has been available to developers?

In his posts on Freescale forums, Christian Zigotzky states he has P1022 board since late 2014. As with Nemo and Cyrus, A-Eon wants Linux first (to see if all features work), OS4 port next. Hardware developement should start even earlier - in 2013 I would assume.

@pavlor

YES, you have the timeline.
So we might assume that the parts have already been purchased.

As such, the design is NOT going to change.

And with about a 2.5 years of likely development time (similar to that of the X1000), the T10XX series would not have been available at the start of the project.
Nor would the low prices set for the T10XX CPUs have been a likely prediction once they were announced.
They cost LESS than than e500mc based CPUs, guys.

But, I don't understand why Hyperion's developers have not been working on a solution to the issue of the spe fpu OR why the Linux testers have not been in the game until recently.

Using the excuse that getting Linux run on the platform as a way of testing the hardware before porting of OS4 does not sit well with me.
First because the hardware has been available for awhile.
And second, because there isn't any real Linux market for this stuff.

With today's dirt cheap, and more powerful, X64 hardware, you would have to be really fanatical to want to run Linux on a PPC.

Last edited by iggy on 25-Oct-2015 at 12:41 AM.

@iggy

Quote:

BTW - Is anyone aware of how long Tabor has been available to developers?

Quite some time, from all accounts.

Quote:

why the Hyperion developers don't have a software solution for hardware that apparently exists.

Because someone needs to implement such a solution. And before anyone can implement such a solution, someone needs to create a suitable kernel for OS4. And the "kernel guy" might just be busy with something else.

That's what gets me about all these discussions about how well or not such a board could theoretically be made to work under OS4 --- they ignore the realities of the work involved in getting OS4 running on it at all, and the observation that even that work is apparently, uhh, "taking its time", to be generous.

@umisef

Quote:

Quite some time, from all accounts.

So...as I asked before, why the delay in getting these in the hands of the Linux guys?

And I don't expect things to be done overnight.
The OS4 developers already have the strain of having to ready the X5000 for release.

Quote:

...how well or not such a board could theoretically be made to work under OS4

I am still kind of stuck on should it rather than could it.

Last edited by iggy on 25-Oct-2015 at 01:50 AM.

@iggy

Quote:

Yes the design work necessary to change the cpu on this board could have been started almost two years ago. But what if production was close when that decision needed to be made?

Then someone has been sitting on a lot of boards for a long time, obviously. Which isn't good business, meaning someone would be very unhappy right now with whoever is responsible for those boards not being able to be sold.


We know that this board has been around for quite some time, but hasn't actually entered the market. The following is speculation, and should be treated as such: The board also would appear to be an ACube design --- it has their trademark Lattice FPGA, it doesn't have a Xorro slot, and it's an entry-level design, which is the market segment which, according to the ACube/A-Eon cooperation should be served by ACube. So how come it's now being marketed as an A-Eon product?
It also feels, to me at least, as if in recent years, ACube and Hyperion haven't exactly been the best of buddies.
So, let's say ACube designed Tabor a few years ago, having contacted Hyperion about OS4 support and having been told "sure, shouldn't be a problem. Usual conditions" by Hyperion (non-technical) management. ACube then enters the component procurement stage, committing to building 1,000 of these lovely low-cost multi-core boards to complement A-Eon's high-end X1000 which is also nearing production. They also ship a prototype to Hyperion, who passes it on to their technical contractors, who promptly respond "Are you crazy? That thing is *nothing* like the PowerPCs OS4 is running on. This is going to take a lot of time, which means a lot of money. Oh, and BTW, that X1000 work is taking longer than expected". At this point Hyperion commercial management decides to focus their limited resources on the already-announced prestige board, and tells ACube "sorry, we spoke too soon. Can't help you with OS4. Good luck selling your boards to the linux/PPC market." There might even have been a bit of a chuckle along the lines of "That will teach them to think twice before doing things like project Moana".

Fast-forward a couple of years, and ACube is still stuck with a whole lot of useless-without-Hyperion-cooperation inventory, and no way, short of throwing a lot of good money after bad, to obtain such cooperation. On the other hand, A-Eon's principal(s) have (financial) leverage over Hyperion, or at least believe they do. So they offer to buy the Tabor design and inventory from ACube, allowing them to recover a part of their investment.

Of course, that leaves A-Eon even more dependent on Hyperion, and given that they are already getting antsy about not being able to ship their X5000 stock because OS4 support is taking its sweet time, Costel's rather pointed statement that OS4 is not running on Tabor yet might well be seen as a not-so-subtle reminder that, while A-Eon might have Hyperion by the short and curlies, the reverse is also true....
(end of speculation. This here just as a reminder that the above is, indeed, pure speculation and not based on any non-public knowledge)

@umisef

Interesting speculation.
And the Lattice FPGA is something I overlooked.

But, at this point further speculation just harms A-eon.
And, while many of you might not believe this, I think they are very important to the continuation of our current market.

@umisef: makes sense.

I add that around 3 years ago ACube was evaluating a 8610/G4 board for the next "Sam" series, which was a good thing for the OS4 land, since the G4 offers good performances both in "integer" and floating point code, especially thanks to the Altivec.

I don't know why then they have changed to the P1022, except for (drastically) cutting the costs, of course. Another reason might be that it could have been a contender for the upcoming e5500-based system...