@matthey
"A MMU is not a problem in FPGA. The problem is Gunnar optimizing for a FPGA to maximize performance in a FPGA and a MMU is counter to his goal. The 68k "MMU" changed significantly and it is likely that a modern MMU would need some changes. ThoR tried to work with Gunnar on a "minimal" MMU design and compatibility layer but Gunnar is unreasonable. The AC68080 has a MPU but no virtual addresses."

I thought Gunnar had open sourced the thing ? Is it so hard that it's not feasible to some small group of people to code that MMU and make a fork of the code ? Maybe it is, I'm just asking...
I must admit I kind of lost interest in it cause I wanted to see some AAA graphic modes implemented (HAM10 etc..), just for the sake it :) Silly I know :) By the way, a new asic would also sell to the atari crowd so I think it would be more feasible.. The question is if there's any semi pirate chip plant in China that would be willing to take it :)
I don't even think it would be feasible, there's probably legislation in way too many places like the one in the US that forces chip makers to introduce backdoors for the spy agencies... That would probably be too much work or even acceptable....

_________________

José

@NutsAboutAmiga

I dont think Hotrod, unlike yourself, ever alluded to having torture devices for female anatomy though. :P


p.s. do you have any idea what Im talking? If you dont I was joking about your unfortunate typo of "breast toaster".

@OneTimer1

Quote:

OneTimer1 wrote: No they are not, on the most embedded platforms, where code size might been an advantage, no one cares about it.

I assume that you aren't a fun of computer architectures and don't follow their evolution, because this is simply not true.

There are TONs of studies on this topic and practically any processor vendor has created extensions or proper ISAs to address this issue, for a very simple reason: it's a Good Thing which brings OVERALL benefits. Overall means on ALL markets: not only on embedded.

Matt reported some literature about it, but you can just search around and you'll find an enormous amount of material which shows and proves why it still matter even with computes having TB of memory available.


@OneTimer1

Quote:

OneTimer1 wrote: @NutsAboutAmiga Quote: NutsAboutAmiga wrote: But its relevant in Amiga land ... So we should rip out the 68k CPU and replace it with an ARM that has Thumb ... */sarcasm* No, we won't do it, because software compatibility is much more important than code density and we could use an ARM only, if it runs 68k code even if it will means 'bloat' compared to 68k CPUs.

Not needed: 68k is already very good and similar Thumb...


@Karlos

Quote:

Karlos wrote: @matthey I'm not condemning PPC because it's objectively bad in some way. Sure the code density is lower than 68K but you have to be very kind of special to think that it makes that much difference in reality - at least in the context of Amiga software.

In such context there's limited memory available.

So, not only from a performance PoV, but even taking into account only the memory used... it still matters...


@Jose

Quote:

Jose wrote: @matthey I thought Gunnar had open sourced the thing ?

Quote:

Is it so hard that it's not feasible to some small group of people to code that MMU and make a fork of the code ? Maybe it is, I'm just asking...

He promised to open source its chipset (SAGA), but not its CPU (which he want to strictly keep for him. Which makes sense: he spent and invested a lot on it).

However SAGA is still closed source and after so many years from his announcement I strongly doubt that he will ever maintain his word.
Quote:

I must admit I kind of lost interest in it cause I wanted to see some AAA graphic modes implemented (HAM10 etc..),

That's crap: forget it.
Quote:

just for the sake it :) Silly I know :)

Well, it has also no software for it...
Quote:

By the way, a new asic would also sell to the atari crowd so I think it would be more feasible.. The question is if there's any semi pirate chip plant in China that would be willing to take it :) I don't even think it would be feasible, there's probably legislation in way too many places like the one in the US that forces chip makers to introduce backdoors for the spy agencies... That would probably be too much work or even acceptable....

Assuming that it's possible, as long as the products exit from China they should respect the laws of the countries where they are delivered.

@Karlos

Quote:

Karlos wrote: You need to compare the typical object code output by your best compilers for the same input code for equivalent optimisation... I mean if you want to have a serious discussion anyway.

Yes.

Examples:-

IBrowse 2.5.9:-

OS 3.x 1025104 bytes
OS 4.x 1979156 bytes
Size ppc/68k = 1.93

A09 - 6800/6801/6809/6301/6309 Assembler

A09_aos3.exe 102240
A09_aos4.exe 191424
Size ppc/68k = 1.87

Duke Nukem 3D

AmigaDuke3D 0.3 555932
Duke3D_AOS4 0.3d 1105190
Size ppc/68k = 1.99

@bhabbott

Quote:

bhabbott wrote: @Karlos Quote: Karlos wrote: You need to compare the typical object code output by your best compilers for the same input code for equivalent optimisation... I mean if you want to have a serious discussion anyway. Yes. Examples:- IBrowse 2.5.9:- OS 3.x 1025104 bytes OS 4.x 1979156 bytes Size ppc/68k = 1.93 A09 - 6800/6801/6809/6301/6309 Assembler A09_aos3.exe 102240 A09_aos4.exe 191424 Size ppc/68k = 1.87 Duke Nukem 3D AmigaDuke3D 0.3 555932 Duke3D_AOS4 0.3d 1105190 Size ppc/68k = 1.99

All apps/game written in C and using the same compiler?

@cdimauro

Quote:

cdimauro wrote: Anyway, translating assembly (not "assembler"! This is the compiler, not the language!)...

Assembly language
Quote:

In computer programming, assembly language (alternatively assembler language...

IBM documentation: Assembler language
Quote:

Assembler language HLASM Language Reference SC26-4940-06 The assembler language is the symbolic programming language that lies closest to the machine language in form and content. The assembler language is useful when: - You need to control your program closely, down to the byte and even the bit level. - You must write subroutines for functions that are not provided by other symbolic programming languages, such as COBOL, Fortran, or PL/I.

From now on I will just call it 'asm' and avoid the nitpicking.

@cdimauro

Quote:

cdimauro wrote: @bhabbott All apps/game written in C and using the same compiler?

Irrelevant, but in the case of A09 and Duke Nuken yes, same compiler. I recompiled A09 with SASC and the size went down from 102240 bytes to 95612 bytes (6.5% smaller).

This isn't a perfect measure of machine code size because many programs include data with a fixed size (eg. text strings) that make the ratio smaller. Both IBrowse and A09 have a lot of it. However in practice it's the total size on disk and in memory that matters, so I think comparing the executable sizes is valid for our purposes.

@fishy_fis

I guess your comment had been funnier if I realized I had made a typo, your reply without any context, sounded like you had forgot to take your medicine.



Randomly accusing someone of being serial killer, is a bit over the top, in particular when you come from the land that built by inmates. That was what I was thinking… at least its funny we can laugh about it now.

Last edited by NutsAboutAmiga on 19-Nov-2023 at 09:12 AM.

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

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: @bhabbott All apps/game written in C and using the same compiler? Irrelevant,

I beg to differ: it's absolutely relevant, otherwise you're comparing apples with oranges.
Quote:

but in the case of A09 and Duke Nuken yes, same compiler.

OK, then it's fine. And I assume that the same compiler options were used. Specifically, for code density measures usually binaries are compiled for size (-Os).
Quote:

I recompiled A09 with SASC and the size went down from 102240 bytes to 95612 bytes (6.5% smaller).

Even better, ok, but it's irrelevant because you can't do the same for PowerPCs.
Quote:

This isn't a perfect measure of machine code size because many programs include data with a fixed size (eg. text strings) that make the ratio smaller. Both IBrowse and A09 have a lot of it.

Which is ok, because data should also be included IMO: some architectures need to store immediates to memory because they have no way to directly specify them in the instructions.

Taking into account only instructions and not counting such data would be like cheating, in my opinion.

Yes, this doesn't directly involve the code, since we're talking about code density, but the overall space used in memory is and should be the relevant thing to be measured here.
Plus, loading constants from data segment/section means that the data cache is stressed as well, hurting the overall performance.
Quote:

However in practice it's the total size on disk and in memory that matters, so I think comparing the executable sizes is valid for our purposes.

For such comparisons only the text/code and data segments/sections should be extracted and counted, because those are the only ones which are loaded in memory.

However it could be a pain to do it and using the overall executable size might be a good compromise anyway. As long as the binaries use the same executable format (e.g.: comparing HUNK vs HUNK is ok. But definitely NOT comparing HUNK vs ELF).

@cdimauro

Quote:

In such context there's limited memory available. So, not only from a performance PoV, but even taking into account only the memory used... it still matters

In theory it does, in practise it doesn't. Nobody on a PPC machine is running a 2MB chip ram only configuration and frankly neither is anyone on a higher end 68K. I have 256MB on my BlizzardPPC. Other than ports of PC titles, no software ever came close to using it all. In fact I used to have a fixed 32MB RAD on there containing an OS extracted to it on cold boot from a selection list, so that I could reduce HD wear and tear. If an executable was 1MB or 2MB never made any practical difference with the sole exception of loading times.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro Quote: In such context there's limited memory available. So, not only from a performance PoV, but even taking into account only the memory used... it still matters In theory it does, in practise it doesn't. Nobody on a PPC machine is running a 2MB chip ram only configuration and frankly neither is anyone on a higher end 68K. I have 256MB on my BlizzardPPC. Other than ports of PC titles, no software ever came close to using it all. In fact I used to have a fixed 32MB RAD on there containing an OS extracted to it on cold boot from a selection list, so that I could reduce HD wear and tear. If an executable was 1MB or 2MB never made any practical difference with the sole exception of loading times.

Well, here you're talking about a quite expanded system which is very very unusual on the Amiga times.

I've absolutely no problem accepting it: such massive amount of memory with a high performance CPU (compared to the 68k systems of the Amiga time) is exceeding the needs of the average Amiga user.

However it would be nice to see how performs a similarly equipped 68k system.

@ppcamiga1

>Software for amiga is made in c/c++.
>"Classic" Amiga may run on any cpu as long as it is full 32 bit big endian.

Yes, it is mad in C and C++, some adaption (for example 68k Os3.2 and PPC OS4) is still needed.

Also software development is a bit easier on OS4 with stuff like Grim Reaper (instead of an app just guru'ing out like in many 68k systems - developing H2-68k took more times than H2-OS4 - the great support by Apollo Computers who provided a hardware helped here, sad that it is exactly their hardware where I did not get it - yet - playable :( I feel bad after they gave me support - but some things I cannot change...).

Still I do not see that I only "have to decide on one". My approach is I do it first on OS4, and then port it over to 68k. There is no sense for only "decide on one". The time for system wars is over.

>anything may be used ppc, sparc, mipc even itanium.


You need a hardware (or an Emulator). The CPU alone is senseless. A comparision can only be done with a concrete system in mind.

>no reasons to use 68k. 68k gives nothing.
>68k is simply slower more expensive more outdated than ppc.

There is a market for 68k. Actually the biggest Amiga hardware is currently probably the Vampire. We are again at the position were we have one Amiga with lower amount of systems which is a "developers dream" (this would be AmigaOS 4 running on PPC where I get all I want, even stuff like GL4ES with Shader support) and one (or several) Amiga(s) which sells in higher numbers but is SEVERELY restricted by performance (reminds me of A4000 and A1200 "back then"). Amiga users since release seem to always go for the technically inferior systems :( If anything this has become more extreme.

Because of all this my dream Amiga is still the systems of A-EON (x1000 and x5000). Though I think Sam is also a great Amiga (also has some flaws, like the 68k systems).


>emulators are emulators.
>it is stupid to made software for emulator
>when simply switch to native code
>made everything run many times faster.

remember there are things like PiStorm. They do not HAVE a native mode (at least not one which can be used ). For the users they feel like "real Amigas". Despite Emulation involved I would compare them more to something like CyberstormPPC, only this time with ARM CPUs. And on a PiStorm with a Pi QM4 module my Alpha version of 68k-Heretic2 runs playable in 800x600.


>there is nothign special in amiga chipset.
>commodore never upgrade sprites to 256 colors.
>commodore never upgrade playfields to 256 colors.

Fully agreed. Apollo upgraded it though. It can be used for modern games (16 Bit highres chunky graphics). The problem - the low speed. Especially low FPU Speed. And incompatible 3D API. Still for old-style games the Apollo hardware will be like "a dream come true". And Vampire-only games are perfectly viable from the number of systems. Just not the kind of games I am doing I am afraid.

Assuming I get my games running fast enough I will even support Apollo-specific featues like their great Gamepad and their possibility to fast stream background music (that part of the code actually already exists and works nicely).

>so no reasons to switch to 68k or x86.

Who speaks of switching ? We are not Highlanders (Christopher Lambert: "There can be only one!!!" ). Market is small enough that it makes sense to support several ones. You said it yourselves "the code is in C/C++". It is possible to support several ones (as long as there are no hardware and API reasons against this, looking at you, Vampire - and I am still trying to support Vampire).

>so no reasons to switch to 68k or x86.

Actually there would be a reason for a switch to x86 (though I am NOT for switching to x86 actually ). A Little Endian OS would add the possibility to support Vulkan API which is the standard for new games. Big Endian only makes it possible to do a (work-intensive) Vulkan->GL4ES port if ever such recent games would be licenced (of course we still can licence 10-20 year old games which do not require Vulkan). Vulkan can ONLY work with a Little Endian OS. It is not as easy as adding Endian-correction BTW.

As to 68k - the argument would exist if there would be an ASIC version of 68080. This would be quite a beast as to performance I think. And if such a thing existed the sensible thing in my opinion would be adding a PCI Slot so recent 3D Hardware can be used. And of course Drivers. Licence Drivers from A-EON. Doing the hardware alone and say "Drivers are not my business" is the WRONG approach.

But again - it is NOT about switching. For example it took me maybe a few hours to get a QEmu setup and test if my PPC games run on QEmu (and find out about one remaining issue and what the reason of it was). This is not about switching. This is about supporting one more platform additionally. I am still extremely doubtful about sales for people using Emulators. For the very reasons you posted ("why should they buy if they can run the native thing?")

Still - at least for games it is easier to run on OS 4.

Remaining issues on the others (and sorry for the game-centric look at it, for other things these platforms of course will be waaaaays better, and Vampire will be perfect for people loving old games):

PiStorm:

- no 3D Hardware support (if MiniGL via Wazp3D runs fast enough I still want to try out)
- Slower due to Emulation overhead - but still playable, even on a Pi3 H2-68k runs in 480x270 playable - actually not sure if a Qm4 might not beat a Sam440 if 3D Hardware is ignored (yeah with 3D Hardware the Sam440 will win against PiStorm Software-Renderer I suspect)
- Smaller screens are not fullscreen but stampbox (I think whoever is working on that stuff should fix that)

Vampire:

- Slower
- 3D Hardware which is fast enough exists
- Slow FPU
- 3D API does not support the AmigaOS standards
- Missing features in 3D Hardware (they got a list from me, both a "must-have" list and a list "would be cool, but I can live with if those are missing and adapt my code to them missing")

QEmu:

- No 3D Acceleration
- MiniGL via Wazp3D exists but too slow
- Slow FPU (probably the reason why MiniGL via Wazp3D too slow)
- Probably also slow due to Video refresh code

I know of course all three platforms have the story "our systems are as powerful as PowerPC OS4 systems". No they are not. At least not regarding modern games. Or even games which were modern 20 years ago.

Still - why should I NOT support them ? I see no reason not to support them if it is possible with reasonable effort (I HOPE I still get the stuff running on Vampire - I will give it my best, the other two are a non-brainer)

If we compare to PowerPC systems:

x1000/x5000:

- Lower amount of users
- Cannot really think of anything else, at least nothing which is not shared by all other Amiga platforms

Sam:

- Slower (though not as slow as 68k systems, actually PiStorm Qm4 might reach Sam speed in software-rendering, I want to do benchmarks)
- Hardware flaws (preventing DMA access for RadeonHD/RadeonRX which limits speed)

Older systems:

- Even Slower (but still at least equal to the fastest of the 68k bunch)
- Cannot use Shader-Hardware (can use older Shader-Hardware but no Warp3DNova Drivers for those)


Do not get me wrong, my games are fully playable on both PiStorm and QEmu. Still compared to OS4 on PowerPC they are "flawed". I am still convinced I can sell games on these platforms.


MagicSN

@MagicSN

The VideoCore on CM4 in theory supports OpenGL3.2ES and Vulkan. Hardware is there, it's a matter of exposing it/creating drivers.

Last edited by Karlos on 19-Nov-2023 at 12:08 PM.

_________________
Doing stupid things for fun...

@Karlos

Yeah, that was my idea when I asked people involved in this PiStorm thing and they said it is not easy.

About Vulkan this probably would not work as long as the OS is Big Endian. But having GL4ES would already be great. All my current games support GL4ES so if there is a solution to run GL4ES on PiStorm (which is based on OpenGLES) then this could be easily supported by the 68k versions.

@MagicSN

I am not necessarily suggesting a straight passthrough, as you say, it would be swamped with problems like this. What we need, I think, is a relatively simple virtual hardware interface that could serve as a target for a guest side implementation of MiniGL, Mesa, Warp3D etc. A sensible interface for GL could at least ensure that all the T&L and shader stuff remains handled on the host side.

I'm sure there's plenty of devil in the detail but I don't think it's completely unachievable to expose the hardware through such an abstraction.

_________________
Doing stupid things for fun...

@Karlos

As I understand it JIT compiler was the OS, in that way better controller over memory mapping, but I can be wrong.

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

@cdimauro

Quote:

cdimauro wrote: I assume that you aren't a fun of computer architectures and don't follow their evolution, ...

Wrong, it's my job and no one there is asking for code density, they are asking for availability.

@Karlos

>I am not necessarily suggesting a straight passthrough, as you say, it would be swamped with >problems like this. What we need, I think, is a relatively simple virtual hardware interface that could >serve as a target for a guest side implementation of MiniGL, Mesa, Warp3D etc. A sensible interface >for GL could at least ensure that all the T&L and shader stuff remains handled on the host side.

Well if someone would implement it I would be willing to support it in my gaming titles. But someone else would need to implement such a system.

Steffen

Karlos Quote:

I put it to you that the code density argument is somewhat moot here. The smallest instruction cache on a PPC machine running OS4 is 16K, which is the 603e on the BlizzardPPC. That goes up to 32K on the 604e. So by your reasoning the 68060, which is the highest performing "true 68K" has the same code density/icache profile as the CSPPC, which already starts at around 200MHz and has a faster bus.

The PPC 603 and 604 suffered from poor performance so the caches were doubled with a die shrink for the 603e and 604e. The 6 stage PPC 604 out clocked the 4 stage PPC 603 but the PPC 603e out clocked the PPC 604e and the most likely reason is the 32kiB I+D L1 cache was the limitation. See the following post for a comparison between 68060, P54C Pentium, PPC 603, PPC 604, Alpha 21064A and Alpha 21164 to see which CPUs should be the easiest to clock up and why.

https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=45079&forum=17&start=20&viewmode=flat&order=0#865037

Karlos Quote:

Yet as anyone whose ever measured it can attest, 68K code JIT executed on that same 604 outperforms the same 68K by a wide margin. You can make the same icache/code density comparison between the 040 and the 603e. And the same facts hold. I myself measured a 10x performance improvement for some compute bound code relative to 040/25 MHz for that specific combination.

A 233MHz PPC 604e is going to outperform a 68060@50MHz by a large margin and likely enough to even emulate it. A 68060@400MHz would have turned the tables for a similar price as a PPC 603e. A 68060@300MHz with a 16kiB I+D L1 cache likely would have been better performance but cost would likely be between the 603e and 604e. Enlarging the data cache is better for performance than removing the PPC instruction cache misses that steal much of the memory bandwidth from data memory accesses. The 68060 should have had the best of both worlds with a 16kiB I+D L1 and good code density but it wasn't allowed to embarrass PPC with their shallow pipelines and fat caches that limiting their clock speeds. What technical feature did the 68060 lack for a high clock speed?

Karlos Quote:

I'm not condemning PPC because it's objectively bad in some way. Sure the code density is lower than 68K but you have to be very kind of special to think that it makes that much difference in reality - at least in the context of Amiga software.

Running native PPC software likely takes at least twice as much memory as on a 68k Amiga. JIT emulation of 68k Amiga software on PPC takes much more memory and drops performance to 1/3 or less. It's not just PPC but PPC is worse than ARM at being resource hungry and the A600GS has 2GiB or 4GiB of memory. The majority of 68k Amigas ran off 2MiB of memory or less.

Karlos Quote:

I don't dislike the PPC architecture. In fact, there's nothing about PPC itself I dislike. I am not a hater. I am, however, a realist. The objection to PPC is that it's too niche and too expensive which is due to the fact that as a desktop processor it basically died the day apple abandoned it for intel. Which was good news for a while - suddenly there was a surge of reasonable second hand, well-engineered hardware, but no, we must only have some new hardware. I am sure OS4 for Mac PPC would've sold far more copies than the rest put together. But that's a different conversation. All the technical arguments for sticking to PPC are absolute unmitigated drivel. Everything written for it that's worthwhile keeping is already portable enough to move to another architecture. There may be some bits and bobs in assembler here and there but it's going to be a small minority for sure. Everything that was said about 68K being a dead end when PPC first appeared applies to PPC now and has done for years.

It is possible to port AmigaOS 4 to another architecture but it would be easiest and most compatible if ported to a big endian architecture where there are not many choices. Supporting more architectures is more difficult than supporting one. One of the reasons why the 68k Amiga remains popular is that it is a standardized system. The small footprint from good code density helps too.

MagicSN Quote:

Yeah, that was my idea when I asked people involved in this PiStorm thing and they said it is not easy. About Vulkan this probably would not work as long as the OS is Big Endian. But having GL4ES would already be great. All my current games support GL4ES so if there is a solution to run GL4ES on PiStorm (which is based on OpenGLES) then this could be easily supported by the 68k versions.

It is possible to do endian conversions at or near copy speed. It is also possible to do endian conversion mappings of whole pages which is a feature of PPC MMUs. What specifically makes a big endian OS difficult for Vulkan?

I thought the big benefit of Vulkan came from better parallelization using SMP. Well, it is written in C instead of C++ for better performance using less memory but that is a good fit for an AmigaOS mostly written in C. Any expectation performance wise compared to OpenGL ES without SMP?