@megol

Remember the version big-endian x86-gcc for Amithlon back in 2002 ?

Sure it lost about 50% performance compared to true native code, but given how much PPC has been lacking even back then it would still have been a good deal......

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

@bison

Quote:

I think they may have trouble selling the 1000 they've already made, especially if the release is delayed far into 2016.

Depends on final price. For 200 EUR, Tabor would sell like hot cakes.

@megol

Quote:

megol wrote: @matthey [...] While x86 still is little endian and that is unlikely to change keeping compatibility is still possible, I've mentioned one way some years ago (address space inversion) and all modern AMD64 variants have support for the MOVBE instruction which does a big endian memory access. This means emulated 68k and "native" big endian AMD32 (64 bit mode using 32 bit pointers) would be compatible in that data structures could be shared and calls/branches between emulated and native code could be done. Disadvantage? Most RMW and RM instructions would have to be done in a RISC style with separate loads and stores. The core of the operating system that is translated to native code could do accesses to internal data with the default little endian memory operations.

Intel's compiler offers the possibility to mark any data as little or big endian, and automatically creates proper code for addressing them, so it will be much easier to change the existing code accordingly, albeit it requires time anyway.

I haven't verified, but I presume that it generates proper MOVBE instructions when needed.

Anyway, and I've already stated, with your proposal the platform is still 32 (31) bit, keeping all its limits. Is it what the post-Amiga people wants?
Quote:

How is that worse than running on PPC?

It should be seen how fast it's. MOVBE is a fast instruction, but abusing of it can degrade performance.


@bison

Quote:

bison wrote: @cdimauro Quote: "If you repeat a lie often enough, people will believe it, and you will even come to believe it yourself." - Adolf Hitler (Mein Kampf) There it is! https://en.wikipedia.org/wiki/Godwin%27s_Law

From your link:

"Godwin's law itself can be abused as a distraction, diversion or even as censorship, fallaciously miscasting an opponent's argument as hyperbole when the comparisons made by the argument are actually appropriate."




@Kronos

Quote:

Kronos wrote: @megol Remember the version big-endian x86-gcc for Amithlon back in 2002 ? Sure it lost about 50% performance compared to true native code, but given how much PPC has been lacking even back then it would still have been a good deal......

At the time there wasn't the MOVBE instruction.

@cdimauro

Quote:

cdimauro wrote: @megol Quote: megol wrote: @matthey [...] While x86 still is little endian and that is unlikely to change keeping compatibility is still possible, I've mentioned one way some years ago (address space inversion) and all modern AMD64 variants have support for the MOVBE instruction which does a big endian memory access. This means emulated 68k and "native" big endian AMD32 (64 bit mode using 32 bit pointers) would be compatible in that data structures could be shared and calls/branches between emulated and native code could be done. Disadvantage? Most RMW and RM instructions would have to be done in a RISC style with separate loads and stores. The core of the operating system that is translated to native code could do accesses to internal data with the default little endian memory operations. Intel's compiler offers the possibility to mark any data as little or big endian, and automatically creates proper code for addressing them, so it will be much easier to change the existing code accordingly, albeit it requires time anyway. I haven't verified, but I presume that it generates proper MOVBE instructions when needed.

Do you mean for compiling the OS?

Quote:

Anyway, and I've already stated, with your proposal the platform is still 32 (31) bit, keeping all its limits. Is it what the post-Amiga people wants?

I haven't said that 32 bit (31 is only limitations in some APIs, not a general thing) is the destination, I just mentioned that the execution of big endian code in emulation of 68k and/or PPC have a solution.
What you are claiming is that making the system compatible with old code makes it impossible to improve on it. Which is hogwash.

We already know the solution to a better future: sandboxing. Then the future system can evolve from a virtualization host (via binary translation) to a more modern system with incompatible APIs, full 64 bit support, SMP, native code etc.

But the problem is (and have been for a very long time) a lack of market. Amithlon was designed to use Linux as a base for that reason and could have provided a good system to evolve from. But if the real system running on the computer is Linux, Windows, BSD etc. why not just use that system instead with a variant of UAE on top? Using UAE as the interface to the machine is trivial comparable with the writing of a new system anyway.

Making a new, native system inspired by AmigaOS requires effort and that requires money.

Quote:

Quote: How is that worse than running on PPC? It should be seen how fast it's. MOVBE is a fast instruction, but abusing of it can degrade performance.

So use an AMD Jaguar core? ;)
But even seriously that is an option: fast execution of MOVBE, reasonable performance and low prices.

Quote:

@Kronos Quote: Kronos wrote: @megol Remember the version big-endian x86-gcc for Amithlon back in 2002 ? Sure it lost about 50% performance compared to true native code, but given how much PPC has been lacking even back then it would still have been a good deal...... At the time there wasn't the MOVBE instruction.

It used BSWAP which can be faster than using MOVBE. But address space inversion would have lower runtime overheads, making the translator would be harder though.

@megol

I think we need to accept that the A-Eon/Hyperion plan needs to be successful with its current products and to grow the user base before we can talk about porting to x64. If the market doesn't grow and the X5000 isn't a success then there is no point throwing good money after bad. Either PPC machines are a success in the short-term or there is no x64 or ARM CPU future only emulation.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@bison

one of the lead developers said that they have not even started yet. Priority is X5000 and they will not start with it before X5000 is there. They have a slow solution (whatever this will mean in reality) for FPU emulation but completely untested. So talking about 2016 for Tabor sounds optimistic to me at the moment.

@cdimauro

stop with your constant "liar" shit. You are as annoying as other people calling everyone "troll". Additional playing the "Hitler" card is not making it better...

@megol

Quote:

megol wrote: @cdimauro Quote: cdimauro wrote: @megol Intel's compiler offers the possibility to mark any data as little or big endian, and automatically creates proper code for addressing them, so it will be much easier to change the existing code accordingly, albeit it requires time anyway. I haven't verified, but I presume that it generates proper MOVBE instructions when needed. Do you mean for compiling the OS?

Yes.
Quote:

Quote: Anyway, and I've already stated, with your proposal the platform is still 32 (31) bit, keeping all its limits. Is it what the post-Amiga people wants? I haven't said that 32 bit (31 is only limitations in some APIs, not a general thing)

I know it: that's why I put 32 and 31.
Quote:

is the destination, I just mentioned that the execution of big endian code in emulation of 68k and/or PPC have a solution.

That's well known from long time (Amithlon showed it in action, too).

But the problems are others: see below.
Quote:

What you are claiming is that making the system compatible with old code makes it impossible to improve on it. Which is hogwash. We already know the solution to a better future: sandboxing. Then the future system can evolve from a virtualization host (via binary translation) to a more modern system with incompatible APIs, full 64 bit support, SMP, native code etc.

Well, that's exactly the kind of changes which I'm already talking about from ages. Are they hogwashes too?
Quote:

But the problem is (and have been for a very long time) a lack of market. Amithlon was designed to use Linux as a base for that reason and could have provided a good system to evolve from. But if the real system running on the computer is Linux, Windows, BSD etc. why not just use that system instead with a variant of UAE on top? Using UAE as the interface to the machine is trivial comparable with the writing of a new system anyway. Making a new, native system inspired by AmigaOS requires effort and that requires money.

Absolutely. In fact, there are people which uses Windows, for example, which immediately and transparently execute WinUAE at the login.

Quote:

Quote: It should be seen how fast it's. MOVBE is a fast instruction, but abusing of it can degrade performance. So use an AMD Jaguar core? ;)

Jaguar can only execute maximum 1 MOVBE per cycle, whereas (from) Haswell can execute 1 (for writing) or 2 (for reading).
Quote:

But even seriously that is an option: fast execution of MOVBE, reasonable performance and low prices.

Absolutely.
Quote:

Quote: At the time there wasn't the MOVBE instruction. It used BSWAP which can be faster than using MOVBE.

BSWAP is required anyway, because MOVBE cannot be used with both registers (only reg to mem, or viceversa).

Anyway, usually this instruction is faster on AMDs, whereas on Intel processors it was slower 'til Haswell. Starting from Haswell, it has the same performance for 32-bit operands, and it's still slower for 64-bit ones. But 32-bit is our case, so there's no problem: same performance for both families.
Quote:

But address space inversion would have lower runtime overheads, making the translator would be harder though.

Do you mean that, for example, the lower 2GB of memory are BSWAP/MOVBE translated (because they are used for the big-endian code), whereas the top/next 2GB ones aren't translated (used by the host/native o.s.)?

@OlafS25

Quote:

OlafS25 wrote: @cdimauro stop with your constant "liar" shit. You are as annoying as other people calling everyone "troll". Additional playing the "Hitler" card is not making it better...

Well, it's YOU that are constantly reporting lies against me, so what else can I do, if not showing your dishonest behavior?

Stop throwing lies, and I'll stop replying you. It's very simple!

@cdimauro

Quote:

Well, it's YOU that are constantly reporting lies against me

It seems you found new friend there. How surprising.

@matthey

Where I disagree with others here is what "Amiga" in future could be. For me it is a retro platform with a chance to grow when new hardware options will be there. That will hopefully be soon the case. I see zero chance for any modernized amiga based OS in todays high competitive markets. You have lots of options for any scenario already, all with more money behind and much more developers. Amiga must find a niche where it can survive and grow to a platform that is interesting at least for independent developers. Most of the developers that were active in the 90s have long left the platform and taken their sources with them, in other cases programs are written in asm that are not portable. That is the reason why NG finally failed, the software base was and stayed 68k and there was a exodus of developers and only few joining later. Many developers that are left today are getting old, there are some younger ones but basically we miss a whole generation now. So the software will not be rewritten for any NG platform. So for me upgraded 68k hardware would be best way to improve situation. Nobody will buy PPC (who not already owns it). Most people in the 68k community do not use amigas to replace modern systems but for fun and retro. Nevertheless, modernized amiga (68k) hardware would offer new chances, both for hardware and software. We will see in a couple of weeks.

@pavlor: and you, as BAT, immediately took the chance to fuel the flame.

I appreciate your contributes to the threads: to be immortalized in the History.

@cdimauro

Quote:

and you, as BAT

I got new name I don´t know! Nice.

Quote:

I appreciate your contributes to the threads: to be immortalized in the History.

It wouldn´t be possible without your help.

@pavlor

he certainly thinks of BATman

@OlafS25

Quote:

Nobody will buy PPC (who not already owns it).

Completely disagree with you. If the X5000 hits a £1,599 price point or less (all in complete system) then I'm interested in what would be my first OS4.x system Messing with Amiga OS 3.9 is not as great as it used to be and the fact the Amiga as a platform is still alive and being developed for in 2015 is awesome. Amiga30 got us some mainstream awareness, A-Eon and Hyperion just need to capitalise on it. I see very little point in trying Raspberry Pi stuff when you can mess around with Amigas!!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

You will buy X5000? Then you must post pictures as evidence then

BTW it was not clear what that price exactly is for, if only for the motherboard or a whole working system. And I think it was without OS license.

@OlafS25

and im the pricer ....,now is time to kick ass to the devil one ... guy pull out yours boing balls or butterfly as you. wish

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@BigD

then I will take it back. At least ONE person is interested

@tlosm

LOL

@OlafS25

Quote:

one of the lead developers said that they have not even started yet. Priority is X5000 and they will not start with it before X5000 is there. They have a slow solution (whatever this will mean in reality) for FPU emulation but completely untested. So talking about 2016 for Tabor sounds optimistic to me at the moment.

I thought the boards were already made and in a warehouse somewhere. I must have remembered that wrong.

_________________
"Unix is supposed to fix that." -- Jay Miner