AGA integration in Apollo core : work in progress

[kolla]

Originally Posted by grond

What special requirements on the chipset do these programs set?

Some programs make use of multiple screens. For example Brilliance, that use one screen as paint canvas and another screen, pulled halfway way down, as tool box screen - the two screens are not necessarily using the same resolution.

[grond]

Originally Posted by Marlon_

Why don't go talk to Gunnar himself and try to have a civilized conversation about it?

They did and proved uncapable of understanding their points are moot. Since those endless discussions were a waste of time, they got removed from the project.

it's not us that needs to be convinced, it's Gunnar that needs to be convinced.

Gunnar does not need to be convinced. He knows what he is doing but they just can't stop whining about their great ideas and visions and how much better it would all be if only Gunnar -- a solid worker but lacking their genius -- were listening to them...

[grond]

Originally Posted by kolla

Some programs make use of multiple screens. For example Brilliance, that use one screen as paint canvas and another screen, pulled halfway way down, as tool box screen - the two screens are not necessarily using the same resolution.

Thanks for the suggestion! I think DPaint would also be an interesting test candidate. We will see how well they work (but only show you once they do, haha).

[meynaf]

Originally Posted by Marlon_

Why don't go talk to Gunnar himself and try to have a civilized conversation about it?

You can't imagine how many times I did this. Gunnar changes his mind only when he finds something himself - nobody can influence.

Originally Posted by grond

They did and proved uncapable of understanding their points are moot. Since those endless discussions were a waste of time, they got removed from the project.

We didn't get removed from the project - we left. I could have remained if i wanted to. Even got contacted back later.
You weren't there when all this happened. Don't speak of something you don't know a thing about.

[kolla]

Originally Posted by grond

Oh, and I do believe that the Amiga community wouldn't object to a 5 GHz 68k even if it was "crippled" by Gunnar's "terrible ISA decisions" which "painted him into a corner"...

About the clocking it would need to compete with the 060 FPU!

[kolla]

Originally Posted by grond

Thanks for the suggestion! I think DPaint would also be an interesting test candidate. We will see how well they work (but only show you once they do, haha).

Be sure to test creating and displaying animations in PAL super hires full video overscan (1472x566) HAM8 then. Or even better - SAGA 1280x720 HAM8, or thereabouts. HAM8 because that is something these old programs understand.

[matthey]

Originally Posted by grond

The POWER8 has the same register design as Apollo Core, i.e. integer registers and wide SIMD registers are the same. The POWER8 runs at 5 GHz and is at the time of writing the fastest processor in the world. So you are wrong with your claim "slows down a critical path". Reality proves you wrong which is something that even non-tech savvy people should understand.

No! Wrong! The POWER8 shares the FPU and SIMD unit register files (vector scalar register file).

https://www.researchgate.net/publica...r_architecture

See Figure 1 which clearly shows the vector scalar register file which is 128x64 bits. What is the "reality" here? Was the truth relative? Will you admit you were wrong and agree with the truth?

I see nothing wrong with the unified POWER8 vector scalar register file. The argument for it is well stated in the article linked above. This arrangement could work well for a 68k FPU and SIMD unit. It is interesting that IBM did not increase the width of the SIMD unit registers which are still 128 bits (wider gives more parallelism) and they halved the number of vector registers from the gaming PPC VMX128 standard (large register files are expensive and power hungry even in the POWER8?).

There have been a few architectures which shared the integer and SIMD unit register files but they are mostly defunct including the Alpha and PA-RISC ISAs. The SIMD units would be stuck with 64 bit wide integer only registers if they were still around today (MMX/AMMX limited). The Motorola m88k RISC architecture did add floating point into the unified integer floating point register file and it was considered a huge mistake with few repeats since the 80s.

[E-Penguin]

[Amiga1992]

Originally Posted by E-Penguin

Same.

[idrougge]

Let's stick to the topic please. This is not a thread about your childish bickering, it's a thread about code density, RISC architectures, vector processing and the width of register files.

[Gorf]

Originally Posted by idrougge

Let's stick to the topic please. This is not a thread about your childish bickering, it's a thread about code density, RISC architectures, vector processing and the width of register files.

What has this to do with AGA integration?

[modrobert]

Originally Posted by grond

OK, let's point out some of the biggest deficiencies in Matt's nonsense...

The POWER8 has the same register design as Apollo Core, i.e. integer registers and wide SIMD registers are the same. The POWER8 runs at 5 GHz and is at the time of writing the fastest processor in the world. So you are wrong with your claim "slows down a critical path". Reality proves you wrong which is something that even non-tech savvy people should understand.

Did I mention already that Gunnar took part in designing the POWER8? Matt, remind us, which real-world CPU did you help design?

I find it a bit strange that POWER8 isn't mentioned at all in the Apollo datasheet.

However, this is mentioned...

100% 680x0 compatible
Apollo/68080 Core
processor for retrogamers

Apollo Core is the natural and modern evolution of latest 680x0 processors. It's 100% code compatible, corrects bugs of 680x0 designs and adds on top most of the cool features which were invented the years after.

Technical discussions aside, this alone gives more credibility to Matt's concerns. The only "nonsense" here is that Apollo is 100% 680x0 compatible.

Originally Posted by meynaf

Amiga community does not want a POWER8. It wants a 68k.

Yes, I agree with the misleading datasheet on that as well.

Originally Posted by grond

The point was that the Apollo ISA decision that Matt likes to criticise does not impose the speed limit he is fantasizing about as can clearly be seen looking at the POWER8 running at 5 GHz with the same register layout.

It also shows how little actual substance there is in his bombastic albeit layman's postings.

Oh, and I do believe that the Amiga community wouldn't object to a 5 GHz 68k even if it was "crippled" by Gunnar's "terrible ISA decisions" which "painted him into a corner"...

I'm actually glad Matt commented, because without your personal attacks stumbling over yourself trying to discredit him I would have missed the POWER8 part.

[grond]

Originally Posted by matthey

No! Wrong! The POWER8 shares the FPU and SIMD unit register files (vector scalar register file).

https://www.researchgate.net/publica...r_architecture

See Figure 1 which clearly shows the vector scalar register file which is 128x64 bits. What is the "reality" here?

"The VSU features a large number of new instructions and
architectural refinements for applications like business
analytics, big data, string processing, and security. The VSX pipelines now supports 2-way 64-bit vector and 128-bit scalar integer data types and new direct GPR-to/from-VSR move operations that provide a fixed-latency and high bandwidth data exchange between the vector and general purpose registers. The added VMX crypto instruction set is targeted towards AES, SHA2 and CRC computations and several instructions have been promoted into VSX to gain access to all 64 architected vector registers."

The VSX supports both scalar and vector instructions for both floating-point and integer, all happily mixed into a single register file.

[Gorf]

Originally Posted by grond

"The VSU features a large number of new instructions and
architectural refinements for applications like business
analytics, big data, string processing, and security. The VSX pipelines now supports 2-way 64-bit vector and 128-bit scalar integer data types and new direct GPR-to/from-VSR move operations that provide a fixed-latency and high bandwidth data exchange between the vector and general purpose registers. The added VMX crypto instruction set is targeted towards AES, SHA2 and CRC computations and several instructions have been promoted into VSX to gain access to all 64 architected vector registers."

The VSX supports both scalar and vector instructions for both floating-point and integer, all happily mixed into a single register file.

We probably see here heavy microcoding and internal register-renaming.
The Power8 is internally surely not what it represents to the outside.

All in all comparing Gunnars 68080 to Power8 is a far fetch.
Power8 can not be a good example, if Apollo wants to go ASIC one day ... unless this ASIC should cost over $5000. Power is fast, but it runs hot and uses lots of silicon.

[matthey]

Originally Posted by grond

The VSX supports both scalar and vector instructions for both floating-point and integer, all happily mixed into a single register file.

IBM did introduce integer SIMD data into the FPU register file but integer is faster than floating point processing so nothing is slowed.

Originally Posted by Workload acceleration with the IBM POWER vector-scalar architecture (Figure 1)

The 64-entry vector-scalar register file. The new VS register file with 64 vector-scalar registers (VSR) is created by extending the 32 floating-point registers (FPR) to 128 bit and combining them with 32 AltiVec registers (VR).

Introducing slow floating point into the fast integer units can slow the integer unit processing of the most important and time sensitive part of the CPU. More ports may be required for the register file potentially slowing it. Enlarging the integer unit register file for more SIMD registers is also potentially slower. These are poor choices for energy efficiency if ever moving to an ASIC as well.

You talk about education but what good is it when you deny what you have learned and the obvious truth? At that point, the only degree you deserve is a degree in propaganda, deception and brainwashing which is good for nothing productive. I hope there are enough critical thinkers here to sort out what degree you deserve.

[idrougge]

Nice to see that the thread is back on track.

[DamienD]

...the real question though is for how long?

Don't let it slip people otherwise I will be forced to close

...everything depends on keeping your posts civil and on topic. No more flaming please.

[sean_sk]

Originally Posted by Yulquen74

So, does this mean that the latest and future cores will ignore the mainboard video and sound resources completely, and use its own instead?

If so, why can they not make this a software feature, enabling either one or the other?

Could someone pleeease answer this question? And preferably from someone 100% in the know.

I have an A600 with a Vampire 2 using GOLD2 core and am only interested (at this stage) in using the RGB output to a CRT monitor. Im not too fussed about AGA since that is what i have my A1200 for and that's patiently waiting for a Vampire 1200. Even using the ECS chipset with this card I have seen massive improvements in speed across the board and I really like my setup the way it is.

I have heard that GOLD3 is supposed to bring massive compatibility improvements as well as an improved turtle mode. If that is the case then this is something I'm really looking forward to. But if it's rumoured to completely bypass the ECS chipset with no choice from the user then this is very concerning. It leaves us CRT users stuck on GOLD2 with no hope of any further improvements. And I seriously dont want to have to buy ANOTHER adapter to convert an HDMI signal back to SCART. Sheesh!!

[grond]

Originally Posted by matthey

IBM did introduce integer SIMD data into the FPU register file but integer is faster than floating point processing so nothing is slowed.

Now that you acknowledge that POWER8 mixes scalar and vector integer data processing with floating point processing at 5 GHz clock frequency just fine, let's get back to what you critisized in Gunnar's ISA decisions:

Originally Posted by matthey

Apollo ISA: 64 bit integer unit registers are shared with 64 bit SIMD unit registers in the ISA
Result: 128, 256, or 512 bit SIMD unit registers would give 128, 256 or 512 bit wide integer unit registers slowing down a critical path
Result: floating point in the SIMD unit would give floating point in the integer unit registers slowing down a critical path

Obviously you were wrong:

ad "result" 1: POWER8 has 128 bit wide SIMD registers combined with scalar integer processing running at 5 GHz. 5 GHz does not appear to be "slowed down" by "a critical path". If you were right, we could expect 64 bit Registers (=less than 128bit) to run even faster than 5 GHz. Fine for me.

ad "result" 2: POWER8 has floating point mixed with integer operations working on the same register file running at 5 GHz. 5 GHz is not "slowed down".

Introducing slow floating point into the fast integer units can slow the integer unit processing of the most important and time sensitive part of the CPU.

Now this is really becoming ridiculous. So IBM introducing integer into floating point is no problem (see above) but introducing floating point into integer is? How is this even possible if in both cases we end up with a mixed scalar/vector integer/floating point unit? How can your claim be right if this mixed unit runs at 5 GHz in a real-world processor? Are you really saying that it matters whether FP or integer were there first in the processing unit before the other got added with the next processor generation?

More ports may be required for the register file potentially slowing it.

Is it possible that each time you write "potentially" (which you do a lot) you just don't know for sure what you are writing about? More ports are only required if you want to increase superscalarity, not if you want to add processing units (which would mean a higher fan-out, if you know what that is). BTW, in the case of the unified register file we find in both Apollo and POWER8 there is no penalty with regard to superscalarity because the legacy units work on respective halves of the unified register file. Hence, your statement about requiring additional ports is nonsense.

Enlarging the integer unit register file for more SIMD registers is also potentially slower.

Which would be why? Please explain the details. Ever noticed how registers increase both in size and number with the ever growing number of transistors per chip? We are talking about 21st century chip technology, not about stuff that were a factor for processors designed in the 1980s.

These are poor choices for energy efficiency if ever moving to an ASIC as well.

You are arbitrarily picking stuff that suits your views and preferences out of four decades of processor development. Now you come up with how larger registers are bad for power efficiency. That was true when you could still count the gates in the processor. Now the registers and the ALU are a minor fraction of the transistor count. This line of thinking is just like you critisized RiVA for a lack of optimisation in the initialisation code where one or two cycles were wasted. Of course, you could with today's technology build a 6510 running with µW of power. But except for cardiac pacemakers hardly anybody needs those.

Let's be precise here: you are not against wide SIMD registers in addition to 32bit integer registers, you say that just having 64bit registers acting both as SIMD and integer registers would be less power efficient. Please explain.

You talk about education but what good is it when you deny what you have learned and the obvious truth? At that point, the only degree you deserve is a degree in propaganda, deception and brainwashing which is good for nothing productive. I hope there are enough critical thinkers here to sort out what degree you deserve.

I guess it is obvious that you were no help to the project because of your unfounded objections and constant refusal of accepting that you are wrong. Since Gunnar won't listen to you any more, you are no telling the entire world.

Your lack of technical expertise shows in that you isolate facts and then put them into the wrong context. Let's make up an example (nothing you actually stated): link registers vs. implicit pushing return addresses to stack. In the 1980s the implicit pushing was a practical feature but resulted in slow subroutine call/return times. Then RISC came up with the Link Register to solve this problem. This was generally considered a good idea for some years. Now Link Registers are a burden because we now have the resources to implement link stacks that completely hide the penalties of old and are ISA-transparent. The Link Stack can even hold predecoding info of the instructions to which the processor will return on subroutine exit and more without the programmer having to know about it. However, one could now claim that implicit pushing of return addresses to the stack are a burden and even cite textbooks from the 80s for that statement. This is how most of your arguments are constructed (e.g. your reference to the Motorola 88k line of processors).

It's so tiring.

[chaos]

Originally Posted by grond

"The VSU features a large number of new instructions and
architectural refinements for applications like business
analytics, big data, string processing, and security. The VSX pipelines now supports 2-way 64-bit vector and 128-bit scalar integer data types and new direct GPR-to/from-VSR move operations that provide a fixed-latency and high bandwidth data exchange between the vector and general purpose registers. The added VMX crypto instruction set is targeted towards AES, SHA2 and CRC computations and several instructions have been promoted into VSX to gain access to all 64 architected vector registers."

The VSX supports both scalar and vector instructions for both floating-point and integer, all happily mixed into a single register file.

I'm not too familiar with the POWER8 arch, but your quote clearly states "GPR-to/from-VSR move operations", which would imply separate GPR & VSR regfiles. So, it looks like it does have separate 'integer-only' regular general purpose registers and separate 128x64 VSR registers. Which in my opinion, makes perfect sense, as using just a single 128x64 regfile for all ops would push power usage much higher.
Now, that doesn't mean that ops on VSR can't be integer, because, why wouldn't they be - even GPUs can do integer math.

The issue with separate regfiles is not (just) of frequency, but mostly power. Look at the latest Intel's AVX512 - power usage is quite a lot higher then previous versions. It just doesn't make sense to use such large regfiles for all operations.