Click Here
home features news forums classifieds faqs links search
5755 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
32 crawler(s) on-line.
 12 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 arthoropod:  30 mins ago
 Marcian:  36 mins ago
 towo2099:  44 mins ago
 Vidar:  49 mins ago
 Fairdinkem:  1 hr ago
 evilFrog:  1 hr 5 mins ago
 pvanni:  1 hr 10 mins ago
 A1200:  1 hr 37 mins ago
 umisef:  1 hr 51 mins ago
 matthey:  1 hr 57 mins ago

/  Forum Index
   /  General Technology (No Console Threads)
      /  Apple moving to arm, the end of x86
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 Next Page )
PosterThread
Hammer 
Re: Apple moving to arm, the end of x86
Posted on 2-Aug-2020 3:24:25
#141 ]
Elite Member
Joined: 9-Mar-2003
Posts: 3967
From: Australia

@matthey

Quote:

matthey wrote:

Are the arguments about the Apollo Core "speculative performance arguments"? The Apollo Core most resembles a 68060 which has some technical information available and can be mostly re-implemented.

Were you suggesting that the 68k won't have good performance because, "Fixed-length instructions make it easier for superscalar pipelining"?

1) The 68060 decodes and converts instructions to a fixed length RISC like encoding in the Instruction Fetch Pipeline before adding to an instruction buffer for the decoupled execution pipes. A single stage table lookup scheme is used for early decode of instructions. In the common case, decoding is easier on the 68k than x86 with the opcode and register/EA fields easier and quicker to find. Decoding problems for the 68k are long instructions and finding the instruction length with the 68020 ISA additions.

2) The 68060 only has a 4 byte/cycle instruction fetch yet can execute up to 3 instructions per cycle. All 32 bit fixed length instruction RISC processors can't be superscalar with this small of a fetch as this is only one instruction per cycle! Fetching smaller code left more bandwidth for data helping to allow a cheaper 32 bit data bus with similar performance to the 64 bit data buses of the competition. Instruction supply uses the most power on low end embedded processors at 42% according to a study. If more performance is desired, an 8 byte/cycle instruction fetch, 3rd integer pipe, dual ported data cache and 64 bit data bus should be potent and efficient.

As we can see, code compression is more of an advantage than a small latency increase in the pipeline. The transistor count for code compression is more than offset by the ICache and memory transistor savings with significant savings in power. The 68060 shows that decoding power was low even on a simple CPU back in the '90s where a complete system would have used less power than most similar performance RISC systems and where the decoding tax of x86 was still a high percentage of energy usage. Superscalar pipelining was no problem for the 68k and I will argue that the 68060 did it more efficiently than most of the competition based on PPA (Power, Performance, Area) data. This is *not* speculative!


68060's up to 3 instructions per cycle execution is nearly pointless when the instruction decode per cycle rate is two.

Classic Pentium's 64-bit bus was a good forward-thinking for 64-bit MMX SIMD (two INT32) and AMD K6's 64bit 3DNow SIMD (two FP32 or two INT32).

Last edited by Hammer on 02-Aug-2020 at 03:31 AM.
Last edited by Hammer on 02-Aug-2020 at 03:26 AM.

_________________
AmigaOS 4.1 FE U1 + MS Windows 10 Pro X64
Intel Core i9-9900K @ 5 Ghz, DDR4-3800 32 GB RAM, MSI GeForce RTX 2080 Ti
AMD Ryzen 9 3900X, DDR4-3200 32 GB RAM, ASUS GeForce RTX 2080
Amiga 1200
Amiga 500

 Status: Offline
Profile     Report this post  
Hypex 
Re: Apple moving to arm, the end of x86
Posted on 2-Aug-2020 18:52:12
#142 ]
Elite Member
Joined: 6-May-2007
Posts: 9983
From: Greensborough, Australia

@matthey

Quote:
There was good reason to encode by the byte in ancient computer history. Instructions and data was fetched in small chunks sometimes as small as a byte so small instructions could sometimes start executing sooner (likewise, little endian sometimes allowed narrow ALU calculations to start sooner with the least significant data).


As you put it ancient computer history. An 8-bit base. But it has served them well. Except the 68K, it might have seemed strange that Motorola made the 8-bit 6800 big endian. Since the trend back then was big endian.

Quote:
An example mostly text program which has better code density on the 8086 than the 68k has the following metrics when optimizing for size on the 68k, x86 and x86_64.


Ok, it looks like 68K wins, but speed isn't as easy to calculate on uneven ground. But what about the 8086?

Quote:
x86 and x86_64 cores require to choose performance optimization (new longer encodings) or size optimization (old specialized byte and stack encodings) with an expected large difference in performance while the 68k can expect good performance when optimizing for size giving the best of both worlds. This is another reason to like the 68k for the embedded market where size optimization is more common and the 68k has a large advantage in energy savings.


That's interesting the longer encodings woukd be faster. x86 did have those large caches. Largely in the PPC days when it struggled clock for clock. And it was said to be because the caches were too short so it lost out against x86 performance. May have been around the time of the 500Mhz ceiling.

Quote:
At introduction in 1979, the 68000 had a 32 bit ISA at a time when most CPUs were still 8 bit (the 16 bit 8086 was introduced in 1978 but it was still optimized for 8 bit). It would have been difficult to imagine that more than 4GiB of address space would ever be useful, memory would be cheap enough to make it possible or that programs would be wasteful enough to make it desirable, especially with the great code density of the 68k. Ironically, the 68k ISA aged better than the competition yet is used less.


I suppose it would be diffcult to imagine it for the general market. There were mainframes I read that had "odd" register widths like 36 bits. Ironically the 68K did have superior features. But being better as we know doesn't win in the end. Intel made their name with producing the world first microprocessor. (Also disputed I read.) And Intel was where money was put. And drove the IBM PC machines. Had IBM chosen the 68K, and some have put it forward it as possible contender, things may be different now. The Mac may still be using 68K, the Amiga wouldn't have needed to shift CPU, and x86 would have been ancient history.

Quote:
Old ARM software needs to be patched to run on new ARM hardware because it only had 26 bit addressing with the upper bits of the PC register used by the Processor Status Register. x86/x86_64 CPUs often support everything but at a cost in complexity. It's easier to use an emulator like DOSBox for old software on x86/x86_64. The 68k can use the whole 32 bit address space and can address it all more efficiently than most modern CPUs. On the Amiga, most software incompatibility problems come from banging the hardware sometimes necessary because the AmigaOS was not optimized or bug free enough.


That's interesting, they restricted ARM that way. May have been perfect for MacOS. A type of "pointer typing" in hardware. Now ARM has managed 64-bit since ages, or is it 60-bit?

Sometimes it is easier to use hardware directly. Especially for graphics. But AmigaOS was also "weird" as the kernel calls didn't use CPU traps like was common, but the user mode library calls.

Quote:
When the 68k was introduced, it was praised for it's abundance of GP registers and when RISC came out it was criticized. RISC needs more than 16 registers for performance and the 68k doesn't. The 68k with 16 registers is within a few percent of the memory traffic (including register spills) of most 32 register RISC CPUs. The 68k often has less memory traffic, fewer instructions to execute and better code density than most compressed RISC encodings like Thumb 2 or microMIPS as they often decrease or restrict the number of available registers. x86_64 cores perform well with 16 registers.


The 68K has a good balance in between. But, it is divided, so only 8 are specific GPRs. Possibly why I read it was criticised for not having 16 simple GPRs. Was RISC criticized for having too many registers? Well it needs them for it's load/store architecture which I think is more limiting than register count. But the 6502 (and 6800?) were also load/store based with less registers. x64 did manage to match register count for 68K in the end finally. Only took them, what, five years after 68K was put to rest? And AMD made it simple GPRs. As simple as x86 could give.

Quote:
It would be possible to add another 8 data registers in a separate mode but it would be difficult to get the kind of consistency I'd like to see without compromises. Gunnar wanted to add them without a separate mode which the majority of developers opposed back in the Natami forum days to his angst. Address registers are more difficult to add without major changes to the encodings, although Gunnar added them too. I made an encoding proposal for increasing the FPU registers to 16 with 3 op instruction variations but it was rejected by Gunnar because it didn't have enough registers. It's ironic that the 68k Apollo Core is adding registers everywhere while the Tabor PPC CPU is reducing registers to save energy. Freescale was wanting to reduce power to compete with ARM while Gunnar wants to compete against x86_64 on the desktop, while in an FPGA. I guess core design is all about priorities no matter how warped.


Apparently the Tabor P1022 CPU also has a 36 bit address width. Somewhat strange with a 32-bit core. But has that terrible SPE that has delayed the release for years, well added to delay. Terrible for OS4 code. Even Freescale scrapped in the later days.

But, doesn't ARM have it's FPU registers? What is the GPR count? I've looked it up but forget the details.

It's rather silly to attempt to compete against x64. Copying MMX was a red flag. Secretly trying to make Amiga Intel inside? Even with the whole 68000 engineering team you couldn't do it. And I think Gunnar needs that team really. I don't consider the Apollo to be the next 68K. He doesn't have the team. The 68K died with the Amiga, unfortunately. It would be like waking the dead after 20 years. Gunnar might as well stick an x64 chip on his board, secretly code a 68k emulator in the firmware, then slap a Vampire symbol on top.

Quote:
An 80 bit FPU has advantages and disadvantages. It can reduce cumulative errors, can reduce costly overflow and underflow exceptions and simplifies some algorithms reducing the number of instructions and improving code density but the wider ALU can add a little latency and, yes, 64 bits is more efficient to access in memory. We already have the 68k FPU and it is nice so I would prefer to keep it for compatibility. Decreasing the precision can rarely cause problems as I warned Gunnar about and it did (Frank Wille reported FPU errors to me from the 68k FPU libraries I worked on which I discovered was his UAE 64 bit FPU emulation). The 80 bit registers could be kept and shared with a 128 bit or wider SIMD unit registers like IBM did in a smart way with POWER.


It would be interesting to share FPU with vectors. Makes sense that way. But then again, that damned SPE in the P1022 does the same thing, with re-encoded instructions taking up FPU+AltiVec space. And we know how that turned out!

I read a thread where Jim Drew said MacOS needs a full FPU in Fusion. Otherwise the window scrollers malfunction. And how it breaks on the Vampire not having a full proper 80-bit FPU. He was disputed as people said ShapeShifter works fine and is therefore superior. He claims ShapeShidter ripped off Fusions code somehow. Now that is a thread on the Vampire forums.

Last edited by Hypex on 03-Aug-2020 at 05:45 PM.
Last edited by Hypex on 02-Aug-2020 at 06:54 PM.

 Status: Offline
Profile     Report this post  
matthey 
Re: Apple moving to arm, the end of x86
Posted on 3-Aug-2020 1:15:01
#143 ]
Cult Member
Joined: 14-Mar-2007
Posts: 758
From: Kansas

Quote:

Hammer wrote:
Why compared a classic Pentium at 75 Mhz against 68060 at 75 Mhz when my classic Pentium PC has 150Mhz which is OC to 166Mhz (simple jumper FSB setting)? Higher clock speed is a feature.


Comparing something similar gives more useful information. In my comparison, the 68060 and Pentium use the same die size, clock speed, voltage, 8kiB ICache/8kiB DCache, are pipelined superscalar with in order execution and use CISC register-memory ISAs. The Pentium has a performance advantage in instruction fetch, data bus width and transistors used. The 68060 has a performance advantage in cache ways and a longer pipeline which is better for clocking up but never leveraged. The Pentium advantages primarily increase CPU cost and energy use while the 68060 advantages primarily increase transistors yet the Pentium uses 28% more transistors than the 68060.

Quote:

The embedded argument does nothing for my raytracing and competitive gaming workloads. I have 4.5KW solar panels on my roof, hence the embedded argument is moot.


The Amiga could use POWER and a PCIe raytracing card. The Amiga could even make this hardware a standard but it will be expensive in low quantity for no more than a few thousand Amiga customers. There wouldn't be a large enough installation base to support development or attract developers which is the problem we have now. In the end, you don't get what you want from the Amiga. The Amiga needs mass production to get back in the game and embedded partners are one way to do that. A single embedded partner may use or sell millions of processors allowing prices to be competitive with ARM but without the royalties or middlemen. Think Raspberry Pi with a reduced footprint. Of course there will be users like you wanting upgraded performance and features but it is necessary to start small and relatively simple. The Amiga 1000 could have been better with a 68020, several times the memory, a hard drive and expansion slots but it wouldn't have been because fewer people would have bought it. It was the cost reduced Amiga 500, which left a lot to be desired performance wise, that turned the Amiga around and then the affordable Amiga 1200 which nearly saved C=. With better management, the Amiga could have made an Amiga like the Raspberry Pi back in the '90s.

Quote:

68K family wasn't 100% compatible with each other which is a PITA. My recent 68020 vs 68040 libraries encounter remind me of PITA.


User mode compatibility is very good although there are a few minor differences. Supervisor mode and the MMU changed significantly.

Quote:

Hammer wrote:
The major component with raytracing is the search problem with intersecting branch math. Bounding volume hierarchy (BVH) tree structure is the search component.

Xbox Series X's Forza Motosport 8 has 4K resolution at 60 fps with raytracing (via RDNA 2 GPU with 52 CUs and DXR Tier 1.1).

Cross-generation games such as BattleField V has additional raytracing overhead when it switches between BVH and legacy non-BVH tree structures. Also, DXR Tier 1.1 has a higher efficiency when compared to DXR Tier 1.0. BattleField V used DXR Tier 1.0.

I use Blender 3D 2.83's hardware-accelerated RT on RTX 2080/2080 Ti cards to speed up raytracing which is faster than 64 cores Zen 2. Blender's 3D engine was reworked for BVH structures.


Some gaming snobs will turn up their nose at even 60 fps while others prefer the higher image quality. Raytracing requires specialized hardware but will likely become more popular and cheaper. It would be nice to bring raytracing to mass produced hardware but it may be too expensive or use too much power to make the 3D standard anytime soon.

Quote:

Hammer wrote:
68060's up to 3 instructions per cycle execution is nearly pointless when the instruction decode per cycle rate is two.


I believe a predicted branch is never issued but rather skipped. Even most RISC processors support multiple cycle instructions so the issue rate can be lower than execute rate. In order execution is limiting here for the 68060 other than FPU instructions where the separate unit allows parallel execution kind of like OoO. The in order integer execution of the 68060 is actually primitive as it doesn't allow the use of the other pipe during multi-cycle instructions and more instructions could use both pipes. The 68060 is missing other modern features as well like a return/link stack which could improve code density by reducing the advantage from inlining code. At least the branch folding reduces the advantage of unrolled loops potentially saving code.

Quote:

Classic Pentium's 64-bit bus was a good forward-thinking for 64-bit MMX SIMD (two INT32) and AMD K6's 64bit 3DNow SIMD (two FP32 or two INT32).


Sure. You want a 64 bit data bus if performance is more important than price. There is always a compromise as most customers don't buy the most expensive hardware possible. The 68060 made good choices which did not compromise performance or energy efficiency and made it more appealing for embedded use where it was successful. Sadly, it wasn't used much for desktops or laptops where Motorola/Freescale was pushing inferior low end PPC processors with even more compromises necessary for embedded use.

 Status: Offline
Profile     Report this post  
matthey 
Re: Apple moving to arm, the end of x86
Posted on 3-Aug-2020 4:15:51
#144 ]
Cult Member
Joined: 14-Mar-2007
Posts: 758
From: Kansas

Quote:

Hypex wrote:
As you put it ancient computer history. An 8-bit base. But it has served them well. Except the 68K, it might have seemed strange that Motorola made the 8-bit 6800 big endian. Since the trend back then was big endian.


The 6800 is an 8 bit CPU (although it does have a 16 bit address bus). If only accessing data a byte at a time then there is no problem with endianess.

Quote:

Ok, it looks like 68K wins, but speed isn't as easy to calculate on uneven ground. But what about the 8086?


The 8086 text program is 780 bytes where the 68k program is 854 bytes but the 8086 program is a DOS .com file which is a raw binary with no header or linking overhead (cool for small text programs).

Memory traffic and instruction counts are high for the 8086 but likely lower than most accumulator architectures like the 6800 or 6502. Accumulator architectures are worse for memory traffic than RISC architectures but usually have better code density due to small instructions even though instruction counts are similar. Register-memory (CISC) architectures are usually better than RISC and accumulator architectures at instruction counts, code size and memory traffic. Most RISC ISAs add registers to try to reduce these performance disadvantages.

Quote:

That's interesting the longer encodings would be faster. x86 did have those large caches. Largely in the PPC days when it struggled clock for clock. And it was said to be because the caches were too short so it lost out against x86 performance. May have been around the time of the 500Mhz ceiling.


It's generally better performance to operate on 32 bit or 64 bit data in registers rather than 8 bit data on the stack like the 8086 was encoded for. It is also poor ISA design to make more frequent instructions longer. Much of the code density advantages of the x86_64 register-memory architecture are gone.


Quote:

I suppose it would be difficult to imagine it for the general market. There were mainframes I read that had "odd" register widths like 36 bits. Ironically the 68K did have superior features. But being better as we know doesn't win in the end. Intel made their name with producing the world first microprocessor. (Also disputed I read.) And Intel was where money was put. And drove the IBM PC machines. Had IBM chosen the 68K, and some have put it forward it as possible contender, things may be different now. The Mac may still be using 68K, the Amiga wouldn't have needed to shift CPU, and x86 would have been ancient history.


IBM didn't want to make the PC hardware too powerful as it would compete with their higher end computers and wanted to make it very open because the U.S. Justice Department was scrutinizing them heavily at the time. In any event, the choice of CPU was fateful. What initially looked like healthy competition turned into a dark age of computing that enveloped everything destroying research, development and creativity.


Quote:

That's interesting, they restricted ARM that way. May have been perfect for MacOS. A type of "pointer typing" in hardware. Now ARM has managed 64-bit since ages, or is it 60-bit?


Some people are talking about 128 bit computers and others are still using the upper bits of 64 bit addresses. Who would have thought of 64 bit embedded processors or even needing the upper bits of 32 bit addresses for embedded? Not ARM I guess. The PC is a regular register in all but the latest ARM ISA so more tricks and instruction variations were often used with it too. The 68k uses the PC implicitly like it should.

Quote:

Sometimes it is easier to use hardware directly. Especially for graphics. But AmigaOS was also "weird" as the kernel calls didn't use CPU traps like was common, but the user mode library calls.


Weird? A microkernel is supposed to stay out of supervisor mode as much as possible. Weird is that the big and slow monolithic kernels are the way people think today.

Quote:

The 68K has a good balance in between. But, it is divided, so only 8 are specific GPRs. Possibly why I read it was criticised for not having 16 simple GPRs. Was RISC criticized for having too many registers? Well it needs them for it's load/store architecture which I think is more limiting than register count. But the 6502 (and 6800?) were also load/store based with less registers. x64 did manage to match register count for 68K in the end finally. Only took them, what, five years after 68K was put to rest? And AMD made it simple GPRs. As simple as x86 could give.


The 68k is generally considered to have 16 GP registers even with the register split. Memory traffic is more in line with 16 GP register than 8 GP registers although it may be like losing a register or two but this could be eased by allowing address register sources in most ALU calculations.

Quote:

Apparently the Tabor P1022 CPU also has a 36 bit address width. Somewhat strange with a 32-bit core. But has that terrible SPE that has delayed the release for years, well added to delay. Terrible for OS4 code. Even Freescale scrapped in the later days.


It's not unusual to have a register for higher address bits than registers will hold. It's basically bank switching. The 68k has support for something similar with the SFC/DFC registers. The MC68060UM states the following, "The source function code (SFC) and destination function code (DFC) registers contain 3-bit function codes. These function codes can be considered extensions to the 32-bit logical address. The processor automatically generates function codes to select address spaces for data and program accesses in the user and supervisor modes. Some instructions use the alternate function code registers to specify the function codes for various operations."

Quote:

But, doesn't ARM have it's FPU registers? What is the GPR count? I've looked it up but forget the details.


32 - 128 bit registers shared between the FPU and SIMD unit for AArch64

Quote:

It's rather silly to attempt to compete against x64. Copying MMX was a red flag. Secretly trying to make Amiga Intel inside? Even with the whole 68000 engineering team you couldn't do it. And I think Gunnar needs that team really. I don't consider the Apollo to be the next 68K. He doesn't have the team. The 68K died with the Amiga, unfortunately. It would be like waking the dead after 20 years. Gunnar might as well stick an x64 chip on his board, secretly code a 68k emulator in the firmware, then slap a Vampire symbol on top.


MMX is not that bad of a fit for an FPGA CPU but it is a poor standard for a modern processor. SIMD units are not very flexible and take large amounts of encoding space. x86/x86_64 CPUs have a lot of baggage from old SIMD standards that are rarely used anymore.

I tried to get Gunnar to focus on a compatible FPU and leave the SIMD unit as experimental when I was on the Apollo Team. He wanted to replace the FPU at first as I had the impression he didn't like it, probably because it didn't have enough registers for him, couldn't easily be turned into a vector FPU and the increased precision is likely slower in FPGA than in a hard chip.

Quote:

It would be interesting to share FPU with vectors. Makes sense that way. But then again, that damned SPE in the P1022 does the same thing, with re-encoded instructions taking up FPU+AltiVec space. And we know how that turned out!


The big problem with the Tabor CPU is incompatibility with the PPC standard. I would prefer to share FPU and SIMD registers which several architectures are doing.

Quote:

I read a thread where Jim Drew said MacOS needs a full FPU in Fusion. Otherwise the window scrollers malfunction. And how it breaks on the Vampire not having a full proper 80-bit FPU. He was disputed as people said ShapeShifter works fine and is therefore superior. He claims ShapeShifter ripped off Fusions code somehow. Now that is a thread on the Vampire forums.


Supposedly, Shapeshifter worked where Fusion broke. It's possible some optimization Jim made for floating point needs the extra precision. Jim probably wants Gunnar to change the Apollo Core and Gunnar probably wants Jim to change Fusion. Jim is almost as much of a character as Gunnar.

Last edited by matthey on 03-Aug-2020 at 04:19 AM.

 Status: Offline
Profile     Report this post  
MEGA_RJ_MICAL 
Re: Apple moving to arm, the end of x86
Posted on 3-Aug-2020 4:39:10
#145 ]
Regular Member
Joined: 13-Dec-2019
Posts: 331
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE

@matthey @hammer



VVVVVVVOOOOOOOOOORRRRRRRRRRRRR

Last edited by MEGA_RJ_MICAL on 03-Aug-2020 at 04:40 AM.

_________________
I HAVE ABS OF STEEL

 Status: Offline
Profile     Report this post  
paolone 
Re: Apple moving to arm, the end of x86
Posted on 3-Aug-2020 14:13:01
#146 ]
Super Member
Joined: 24-Sep-2007
Posts: 1070
From: Unknown

@MEGA_RJ_MICAL

Quote:

MEGA_RJ_MICAL wrote:
@matthey @hammer



VVVVVVVOOOOOOOOOORRRRRRRRRRRRR


This.

 Status: Offline
Profile     Report this post  
BigD 
Re: Apple moving to arm, the end of x86
Posted on 3-Aug-2020 15:49:29
#147 ]
Elite Member
Joined: 11-Aug-2005
Posts: 5370
From: UK

@MEGA_RJ_MICAL

Reminds me of this on Sesame Street:

Katy Perry & Elmo Music Video

Probably about as ill advised as discussing how the 060 is better than the Pentium at the same clock speeds / ray tracing / the History of Intel & Motorola on a thread about Apple moving to Arm!

Back on topic; rumours are that the MacBook Arm laptop will be as cheap as $800! At that price my guess is that people will forgive the loss of Boot Camp!

Last edited by BigD on 03-Aug-2020 at 03:51 PM.

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

 Status: Offline
Profile     Report this post  
Hypex 
Re: Apple moving to arm, the end of x86
Posted on 3-Aug-2020 19:06:53
#148 ]
Elite Member
Joined: 6-May-2007
Posts: 9983
From: Greensborough, Australia

@matthey

Quote:
The 6800 is an 8 bit CPU (although it does have a 16 bit address bus). If only accessing data a byte at a time then there is no problem with endianess.


LOL. I meant the trend back then was little endian. Taking things like the 8086, Z80 and 6502 into account. I suppose the 6800 didn't have much competition so they were free to chose the endian.

Quote:
The 8086 text program is 780 bytes where the 68k program is 854 bytes but the 8086 program is a DOS .com file which is a raw binary with no header or linking overhead (cool for small text programs).


That's a few more bytes than the rest. I used to examine PC executables and noticed an MZ magic code. Never knew what it meant. Microsoft Z?

Quote:
Memory traffic and instruction counts are high for the 8086 but likely lower than most accumulator architectures like the 6800 or 6502. Accumulator architectures are worse for memory traffic than RISC architectures but usually have better code density due to small instructions even though instruction counts are similar. Register-memory (CISC) architectures are usually better than RISC and accumulator architectures at instruction counts, code size and memory traffic. Most RISC ISAs add registers to try to reduce these performance disadvantages.


Interesting contrast there.

Quote:
It's generally better performance to operate on 32 bit or 64 bit data in registers rather than 8 bit data on the stack like the 8086 was encoded for. It is also poor ISA design to make more frequent instructions longer. Much of the code density advantages of the x86_64 register-memory architecture are gone.


I would say operating on the widest size in a register would be better for performance.

Quote:
IBM didn't want to make the PC hardware too powerful as it would compete with their higher end computers and wanted to make it very open because the U.S. Justice Department was scrutinizing them heavily at the time. In any event, the choice of CPU was fateful. What initially looked like healthy competition turned into a dark age of computing that enveloped everything destroying research, development and creativity.


Now IBM don't want to make the PPC hardware too powerful either. But it's partly their fault for x86 taking over everything. Well, you can be creative, as long as that creativity was on x86, and pushed the architecture futher. Even Apple was pressured for years to go x86, with things like Copland project, avoided it for decades and finally commiting to it after they just went 64-bit. Perhaps, given the choice was narrowed down to x86 and nothing else I see, is a sign of the times.

Quote:
Some people are talking about 128 bit computers and others are still using the upper bits of 64 bit addresses. Who would have thought of 64 bit embedded processors or even needing the upper bits of 32 bit addresses for embedded? Not ARM I guess. The PC is a regular register in all but the latest ARM ISA so more tricks and instruction variations were often used with it too. The 68k uses the PC implicitly like it should.


I've thought about 128-bit CPUs for years. Infact, I've been thinking about 256-bit CPUs lately. In my head I consider a CPU with 256-bit data, but maybe just 64-bit addresses for now. Just a thought. I have noticed it is common to do some pointer tagging for 64-bit. Given what happened to 32-bit, this looks like a bad idea. Even if the data limit is way more exponential with way more space in lesser bits compared to 32 bit limits.

Quote:
Weird? A microkernel is supposed to stay out of supervisor mode as much as possible. Weird is that the big and slow monolithic kernels are the way people think today.


When I read up on system calls, it is more common to use a specific CPU trap. x86 examples have traps. Atari ST, traps. Mac OS, traps.

Quote:
The 68k is generally considered to have 16 GP registers even with the register split. Memory traffic is more in line with 16 GP register than 8 GP registers although it may be like losing a register or two but this could be eased by allowing address register sources in most ALU calculations.


Could be but it doesn't seem right. Stealing A7 for SP seemed strange as well.

Quote:
It's not unusual to have a register for higher address bits than registers will hold. It's basically bank switching. The 68k has support for something similar with the SFC/DFC registers. The MC68060UM states the following, "The source function code (SFC) and destination function code (DFC) registers contain 3-bit function codes. These function codes can be considered extensions to the 32-bit logical address. The processor automatically generates function codes to select address spaces for data and program accesses in the user and supervisor modes. Some instructions use the alternate function code registers to specify the function codes for various operations."


Oh no it looks like the x86 extending 16 bits to 20 trick. I wonder if this was used to go beyond the 4GB barrier? Or even 2GB. Or used within 32-bit space?

Quote:
32 - 128 bit registers shared between the FPU and SIMD unit for AArch64


Another sharing example.

Quote:
MMX is not that bad of a fit for an FPGA CPU but it is a poor standard for a modern processor. SIMD units are not very flexible and take large amounts of encoding space. x86/x86_64 CPUs have a lot of baggage from old SIMD standards that are rarely used anymore.


MMX is designed for x86 arch. May be CISC. But how well can fit into 68k arch? And ASM format of source,dest.

Quote:
tried to get Gunnar to focus on a compatible FPU and leave the SIMD unit as experimental when I was on the Apollo Team. He wanted to replace the FPU at first as I had the impression he didn't like it, probably because it didn't have enough registers for him, couldn't easily be turned into a vector FPU and the increased precision is likely slower in FPGA than in a hard chip.


Replacing it would be more complicated. But a hybrid FPU/SIMD sounds too much like a Tabor P1022. Any code using FPU would break. And anyone with a powerful 68K would really want to use powerful software. Well I would.

Quote:
The big problem with the Tabor CPU is incompatibility with the PPC standard. I would prefer to share FPU and SIMD registers which several architectures are doing.


That's exacly what the Tabor CPU is doing, haha. The SPE, I read, has a hybrid FPU/SIMD unit for the best of both worlds. Or merging them for a a useful compromise. Useful enough.

Quote:
Supposedly, Shapeshifter worked where Fusion broke. It's possible some optimization Jim made for floating point needs the extra precision. Jim probably wants Gunnar to change the Apollo Core and Gunnar probably wants Jim to change Fusion. Jim is almost as much of a character as Gunnar.


Jim was blaming MacOS. That somehow needed those 80 bits. People wanted a Vampire optimised version of Fusion.

Last edited by Hypex on 04-Aug-2020 at 04:57 PM.

 Status: Offline
Profile     Report this post  
matthey 
Re: Apple moving to arm, the end of x86
Posted on 3-Aug-2020 19:59:02
#149 ]
Cult Member
Joined: 14-Mar-2007
Posts: 758
From: Kansas

Quote:

BigD wrote:
Probably about as ill advised as discussing how the 060 is better than the Pentium at the same clock speeds / ray tracing / the History of Intel & Motorola on a thread about Apple moving to Arm!


We talked about ARM and the technical and business details of what made the transition possible too.

Quote:

Back on topic; rumours are that the MacBook Arm laptop will be as cheap as $800! At that price my guess is that people will forgive the loss of Boot Camp!


That would be a huge price cut Apple is passing on to customers. I knew there would be cost savings from using the same architecture for iPhone, iPad, Mac laptops and Mac desktops but this would be more than I expected. I wonder if they gave up some margin to ensure a smooth transition to ARM. Laptop owners with improved battery life are less likely to complain than desktop users being shorted on performance though.

 Status: Offline
Profile     Report this post  
billt 
Re: Apple moving to arm, the end of x86
Posted on 3-Aug-2020 23:43:41
#150 ]
Elite Member
Joined: 24-Oct-2003
Posts: 3154
From: Maryland, USA

It seems that Nvidia wants to buy Arm. For reals. I wonder what that would do to the situation... I'm surprised Apple isn't bidding, they are insanelty rich and have an interest in keeping ARM reasonably accessible to themselves...

https://www.bbc.com/news/technology-53637463

_________________
All glory to the Hypnotoad!

 Status: Offline
Profile     Report this post  
evilFrog 
Re: Apple moving to arm, the end of x86
Posted on 4-Aug-2020 0:13:04
#151 ]
Regular Member
Joined: 20-Jan-2004
Posts: 352
From: UK

@billt

Quote:

billt wrote:
It seems that Nvidia wants to buy Arm. For reals. I wonder what that would do to the situation... I'm surprised Apple isn't bidding, they are insanelty rich and have an interest in keeping ARM reasonably accessible to themselves...

https://www.bbc.com/news/technology-53637463



"Let’s have a chat about those Radeon chips you keep shipping, Mr Cook..."

_________________
"Knowledge is power. Power corrupts. Study hard, be evil."

 Status: Offline
Profile     Report this post  
matthey 
Re: Apple moving to arm, the end of x86
Posted on 4-Aug-2020 2:26:32
#152 ]
Cult Member
Joined: 14-Mar-2007
Posts: 758
From: Kansas

Quote:

billt wrote:
It seems that Nvidia wants to buy Arm. For reals. I wonder what that would do to the situation... I'm surprised Apple isn't bidding, they are insanely rich and have an interest in keeping ARM reasonably accessible to themselves...

https://www.bbc.com/news/technology-53637463


Apple has a huge pile of cash sitting overseas they can't bring home without high taxes so ARM wouldn't be a bad investment for them but it may not be as important to them as Nvidia. I doubt Apple's ARM architectural license could be revoked so they have what they need. If Nvidia did something Apple didn't like with ARM then they could switch architectures. Apple has their own low power GPU technology so they can and do make their own integrated SoCs saving costs. Nvidia probably wants to make integrated SoCs themselves to better compete with AMD. Nvidia has the most advanced ray tracing technology yet the next generation Sony and Microsoft consoles will be using AMD SoCs with ray tracing technology. Apple could be hurt with the competition using a Nvidia ARM ray tracing SoC. Apple could be forced to license GPUs again although there is another possibility. Servers could do the ray tracing and stream it to low power devices. Google streams games with a service called Stadia but latency and internet connection dependence are issues.

https://www.digitaltrends.com/game-reviews/google-stadia-review/

The Amiga may have been too far ahead of its time with its integrated gfx. The closest we get to a single chip Amiga SoC may be the Vampire. Most low end hardware is sluggish and has several times the footprint of the Amiga. Even the FPGA Vampire seems pretty responsive with a few lines of code like the following video demonstrates using only sprites and the copper (no bitmap rendering and practically 0% CPU usage).

https://www.youtube.com/watch?v=Is3V4BhwWbU&feature=youtu.be

The best computer hardware in the world is not competitive in performance after falling behind a few die shrinks but the design can still be good and competitive in price. Old technology is too often thrown in the scrap heap and forgotten but it may be good again if modernized.

Last edited by matthey on 04-Aug-2020 at 06:10 PM.
Last edited by matthey on 04-Aug-2020 at 02:54 AM.

 Status: Offline
Profile     Report this post  
MEGA_RJ_MICAL 
Re: Apple moving to arm, the end of x86
Posted on 4-Aug-2020 4:57:34
#153 ]
Regular Member
Joined: 13-Dec-2019
Posts: 331
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE

@billt

Quote:

I'm surprised Apple isn't bidding, they are insanelty rich and have an interest in keeping ARM reasonably accessible to themselves


Amiga Friends,

it appears that among other hard realities of the World Out There™, you are also not familiar with those ugly laws against monopolies.

"Antitrust", my dear friends.

Do you really believe Apple would be allowed to purchase the IP to the architecture that empowers all of their competitors? They would have done so, with a hostile takeover and at double the value of thr company, ages ago.

Oh what an interest world it would be without such unfair showstopper regulations.

Signed
MRJM

_________________
I HAVE ABS OF STEEL

 Status: Offline
Profile     Report this post  
fishy_fis 
Re: Apple moving to arm, the end of x86
Posted on 4-Aug-2020 6:03:26
#154 ]
Super Member
Joined: 29-Mar-2004
Posts: 1905
From: Australia

Looks like Nvidia is very serious about its acquisition of ARM.

I hope it happens. It'll be a circus.
Apples arrogance may bite them in the foot. And now it seems likely their lifeblood will be owned by the company they are fighting with.

Good times.

Also, sure,....with %85+ market share and growing now that x86-64 as had a big kick up the rear via AMD I'm sure a single vendor who have a single digit market share changing arches in a few years will be the death of it.

Only Amiga makes it possible.

 Status: Offline
Profile     Report this post  
fishy_fis 
Re: Apple moving to arm, the end of x86
Posted on 4-Aug-2020 6:06:45
#155 ]
Super Member
Joined: 29-Mar-2004
Posts: 1905
From: Australia

@Hammer

Quote:
Classic Pentium's 64-bit bus was a good forward-thinking for 64-bit MMX SIMD (two INT32) and AMD K6's 64bit 3DNow SIMD (two FP32 or two INT32)


At the time maybe. These days Intel are more or less begging people not to use it anymore due to it's awful performance (relative to modern tech).

And for some reason the apollo team saw it a good thing to clone in recent times.

Only Amiga makes it possible.

 Status: Offline
Profile     Report this post  
fishy_fis 
Re: Apple moving to arm, the end of x86
Posted on 4-Aug-2020 15:20:55
#156 ]
Super Member
Joined: 29-Mar-2004
Posts: 1905
From: Australia

@MEGA_RJ_MICAL

The 2 bumbling grumpy old men from The Muppets......

Single most concise and articulate post on an Amiga forum in decades.
The parallel is simultaneously uncanny, frightening, and hilarious.

Only Ami.....

bah, people must get it by now.

I tried to leave, but the various types of comedy gold make it difficult.
This falls under the humorous type.

Last edited by fishy_fis on 04-Aug-2020 at 03:21 PM.

 Status: Offline
Profile     Report this post  
matthey 
Re: Apple moving to arm, the end of x86
Posted on 4-Aug-2020 20:34:56
#157 ]
Cult Member
Joined: 14-Mar-2007
Posts: 758
From: Kansas

Quote:

MEGA_RJ_MICAL wrote:
Amiga Friends,

it appears that among other hard realities of the World Out There™, you are also not familiar with those ugly laws against monopolies.

"Antitrust", my dear friends.

Do you really believe Apple would be allowed to purchase the IP to the architecture that empowers all of their competitors? They would have done so, with a hostile takeover and at double the value of thr company, ages ago.


I doubt the U.S. would stop Apple or Nvidia from buying ARM. The current U.S. administration and many congressman are more focused on protecting technology from China and Russia than oligopolys. A good example is TikTok which Microsoft is being encouraged to buy after showing some interest. The U.S. wants to bring foreign jobs and manufacturing, especially high tech manufacturing with security concerns, back to the U.S. This can be seen with the subsidizing of U.S. based chip foundries and rare earth mineral mining. Tariffs have become an economic weapon. There is an economic war being waged between the oppurtunistic micromanaged economy of China and the U.S. military industrial complex who both want bigger, stronger and more globally competitive businesses under their control.

Last edited by matthey on 04-Aug-2020 at 09:03 PM.

 Status: Offline
Profile     Report this post  
megol 
Re: Apple moving to arm, the end of x86
Posted on 5-Aug-2020 20:33:23
#158 ]
Regular Member
Joined: 17-Mar-2008
Posts: 344
From: Unknown

@fishy_fis

Quote:

fishy_fis wrote:
@Hammer

Quote:
Classic Pentium's 64-bit bus was a good forward-thinking for 64-bit MMX SIMD (two INT32) and AMD K6's 64bit 3DNow SIMD (two FP32 or two INT32)


At the time maybe. These days Intel are more or less begging people not to use it anymore due to it's awful performance (relative to modern tech).

That in it's later Intel iterations are so massive a large subset of shipped chips either don't implement it or implement it in a gimped form, so power consuming executing a single instruction can downclock the whole core or even larger parts of the chip for significant time.

Quote:

And for some reason the apollo team saw it a good thing to clone in recent times.

Do you have any idea why MMX was the SIMD format for early x86? Do you realize why wider and more complex designs aren't necessarily better for a FPGA softcore?
(of course not)

Quote:

Only Amiga makes it possible.

Do something better yourself.

I don't like the AMMX idea nor implementation for the Apollo core btw.

 Status: Offline
Profile     Report this post  
fishy_fis 
Re: Apple moving to arm, the end of x86
Posted on 6-Aug-2020 0:40:33
#159 ]
Super Member
Joined: 29-Mar-2004
Posts: 1905
From: Australia

@megol

Quote:
Do you have any idea why MMX was the SIMD format for early x86? Do you realize why wider and more complex designs aren't necessarily better for a FPGA softcore?
(of course not)


Do you understand that better needn't be either wider nor more complex?
(of course not).

Quote:
Do something better yourself.


Why would I waste my time even trying?
The Amiga scene is a joke.
Im only here for the laughs.

 Status: Offline
Profile     Report this post  
Rose 
Re: Apple moving to arm, the end of x86
Posted on 6-Aug-2020 11:46:53
#160 ]
Cult Member
Joined: 5-Nov-2009
Posts: 707
From: Unknown

@fishy_fis

Quote:
The Amiga scene is a joke.
Im only here for the laughs.


Welcome to Step 5: Acceptance. Where you will get joy from conversations of benefits of ramming square peg on round hole.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle