@cdimauro

Quote:

Why? Actually the opcode IS at the beginning of the instruction (LSBs): not at the end.

You know, that might depend on what you consider the beginning because apparently little endian systems aren't legit, unless they are also bit reversed ;)

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro Quote: Why? Actually the opcode IS at the beginning of the instruction (LSBs): not at the end. You know, that might depend on what you consider the beginning because apparently little endian systems aren't legit, unless they are also bit reversed ;)

Well, that's the source of all last disputes on the argument, I think: (not) being on the same page on definitions.

last thing from original hardware that is still important and
classic amiga have to have is 32 bit big endian cpu, other than in pc.
today it means no x86 no arm and no risc-v.
it is not important what cpu is used as long as data and code is 32 bit big endian.
sparc, mips, s86, ppc, itanium etc. use whatever want. why not.
sparc amiga may be interesting. cpu from commodore era.
many fpga implementation exist. why not.

@Thread

QEmu could now emulate AmigaOne on PC giving you the full AmigaOne experience without buying one:

http://amiga-news.de/en/news/AN-2023-12-00009-EN.html

Most of you knew they could have used QEmu for Pegasos2 emulation, but a real Amigan would only go for AmigaOne emulation.

---

@ppcamiga1

Quote:

ppcamiga1 wrote: classic amiga have to have is 32 bit big endian cpu,... it means ... no arm ...

1st
Some ARM can run in big endian mode, but it's not supported widely.

2nd
'classic amiga' is a term introduced to alienate 'Amigas' in favour to AmigaOnes, in reality the name 'Amiga' never changed on the systems I bought.

Last edited by OneTimer1 on 03-Dec-2023 at 03:07 PM.
Last edited by OneTimer1 on 03-Dec-2023 at 03:06 PM.
Last edited by OneTimer1 on 03-Dec-2023 at 02:16 PM.

@ppcamiga1

Well that's you ****ed then, because no CPU supports bellendian.

_________________
Doing stupid things for fun...

@OneTimer1

Quote:

OneTimer1 wrote: @Thread 'classic amiga' is a term introduced to alienate 'Amigas' in favour to AmigaOnes, in reality the name 'Amiga' never changed on the systems I bought.

*

@cdimauro

Nobody cares about BIOS. Users will not notice what is done in BIOS internally.

Please note that nobody takes arguments which are just taken for the sense of strengthen your point instead of making sense any serious.

>They are PCs with the only difference of the x86 CPU being replaced with a PowerPC one.

Try run Word or World of Warcraft on them. It won't run. So they are not PCs.

Or you just show a non-Amiga-user an AmigaOne (the GUI and everything) and ask him if this is a PC. He will look at it and say "I do not know what this is but obviously it is no PC".

Amiga was already about the operating system in late 90s. Nobody cared on the crappy custom chipset.

MagicSN

cdimauro Quote:

I see two problems then. First is that the you need anyway to follow the VBCC changes and adapt your new backend as well. So, something like GCC could happen (albeit it's unlikely, since I don't see many progresses on VBCC), and rebasing each time the changes could be a nightmare. Second is the copyright: VBCC is not open and even if you create a new backend for it then you're not allowed to release products based on VBCC without a permission / agreement with the author.

A new 68k backend for vbcc would need to be distributed separately from vbcc and use significantly different code so as not to violate copyrights, at least without permission. I don't think it would be difficult to get permission but there would be no guarantee a new backend would ever replace the old, even if it became overall better. A replacement would likely not be as simple, compact, have scrunched together code and have German comments. It would be possible to have English and German comments but that enlarges the code like not scrunching together the code.

cdimauro Quote:

Yes, but Bebbo has a more modern version and with a much better backend: AFAIR it's better than the 2.95. The only thing that I don't understand (or I simply don't know if there are some reasons) is why its changes aren't upstreamed.

That would be great if Bebbo's GCC changes are "much better" than GCC 2.95.3. I haven't kept up on the project so I don't know the results but it is useful even if it can't match GCC 2.95.3 as it brings much more modern C and GCCism support. It is useful to fork source code so it can be experimented with. I would think improvements could be fed back into the active source code but there can be political resistance with GCC developers not wanting to change existing working code for an architecture with no new hardware. The GCC developers would rather kill the 68k backend and support which they tried.

cdimauro Quote:

The main problem is the lack of C++ support. Which is ok: C++ is a monster with big developments: it requires HUGE effort even for supporting some old version. Which, unfortunately, restricts VBCC audiance.

Volker looked into supporting embedded C++ which is a subset of C++ but it never took off.

https://en.wikipedia.org/wiki/Embedded_C++

Even a subset would be useful as Apple uses a different subset that avoids heavy C++ features. Maybe there wasn't enough input from developers before creating the standard.

cdimauro Quote:

Indeed and it was really fun watching the video (I already know and studied the ZCe extension): it's clear admission that RISC-V sucks at code density (20-25% worse is a HUGE difference!). It's ever more fun when I think that its great architects reserved beforehand 75% of the opcode space only for the compressed / 16-bit instructions. And they, still, failed... Anyway, this is a testament of the fact that CISC was and still is a much better macroarchitecture family compared to RISCs. BTW, here are the statistics: https://docs.google.com/spreadsheets/d/1bFMyGkuuulBXuIaMsjBINoCWoLwObr1l9h5TAWN8s7k/edit#gid=1679419155 It's evident that the biggest contributes to the code density improvements are coming from the PUSH/POP with multiple registers and the ability to call "far" subroutines. The first is an advantage that 68ks had since the beginning. The second is common for almost any CISC architecture. Again, a testament of how much better CISCs are...

Good results from CISC like RISC-V extensions but they have the same problem ARM had before AArch64 which was lack of standardization. Actually, it's not even as bad as ARM was. I counted 95 RISC-V extensions.

https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions

The hardware configuration line when compiling will end up being several lines long. SiFive wants better standardized code density using the new compressed extensions.

SiFive's case for retaining Zc* in RVA
https://www.reddit.com/r/RISCV/comments/176g4a9/sifives_case_for_retaining_zc_in_rva/?rdt=49747

Qualcomm wants to move away from ARM with the tightening of ARM IP and the lawsuits but they want simpler decoding for their cores which were using AArch64. Wasn't RISC-V decoding supposed to be simple and the compressed extension optional?

cdimauro Quote:

Why? Actually the opcode IS at the beginning of the instruction (LSBs): not at the end.

I will address this question in your thread on decoding where it is more appropriate and technical when I have time.

NEx64T - #2: opcodes structure for simple decoding
https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=45094&forum=17

@MagicSN

Nobody cares what an ordinary windows user thinks a PC is. We are Amiga users of 30+ years. You won't find a bigger group of factually correct or GTFO irretrievably-far-along-the-spectrum dwellers on the interweb.

I was a puritanical, nay fanatical, Amiga user until 2007. I've used AmigaOS on Amiga, Amithlon and UAE, OS4 on Amiga 1200/PPC and AmigaOne/G4, MorphOS (1.3 only), AROS on x86.

Of all of these, the A1200, with all it's Frankenstein expansions, was the one that gave the most joy and the only one that ever felt "complete".

To say it's all about the OS is a bit disingenuous.

Last edited by Karlos on 03-Dec-2023 at 08:39 PM.

_________________
Doing stupid things for fun...

@Karlos

The odd thing being that Pistorm uses arm in big endian mode

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Nothing odd about that. It's a very logical solution.

_________________
Doing stupid things for fun...

MagicSN Quote:

Nobody cares about BIOS. Users will not notice what is done in BIOS internally. Please note that nobody takes arguments which are just taken for the sense of strengthen your point instead of making sense any serious. >They are PCs with the only difference of the x86 CPU being replaced with a PowerPC one. Try run Word or World of Warcraft on them. It won't run. So they are not PCs.

Your x86 emulator isn't good enough or PPC is too weak for good x86 emulation? Maybe better x86 hardware compatibility is needed?

X86 Extension for RISC-V?
https://forums.sifive.com/t/x86-extension-for-risc-v/1319

RISC-V left most of the encoding space for customization. Maybe NEx64T could be encoded into the custom encoding space since RISC-V and NEx64T both use a variable length 16 bit encoding. Maybe a JIT acceleration extension is good enough though?

RISC-V J Extension Working Group
https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/esYoby-4_GU

MagicSN Quote:

Or you just show a non-Amiga-user an AmigaOne (the GUI and everything) and ask him if this is a PC. He will look at it and say "I do not know what this is but obviously it is no PC". Amiga was already about the operating system in late 90s. Nobody cared on the crappy custom chipset.

The hundreds of thousands of THEA500 Mini customers and tens of thousands of Hyperion AmigaOS 3.x customers still don't count? It's all about AmigaOS 4 without 64 bit and SMP for low thousands of customers in almost 2024? When will the elitism end?

@MagicSN

Quote:

MagicSN wrote: @cdimauro Nobody cares about BIOS. Users will not notice what is done in BIOS internally.

That's obvious, but YOU made some PRECISE statements and I've "just" illustrated how is the situation reporting FACTs.

Changing the topic is, obviously, a Red herring...
Quote:

Please note that nobody takes arguments which are just taken for the sense of strengthen your point instead of making sense any serious.

"Nobody" is just you that are you trying to change the topic and discredit my replies because you don't like them.

If there's something which you think is wrong, I'm more than happy to see your writings dismantling them. If you're able to do it, of course (which is not granted, looking at this comment).
Quote:

>They are PCs with the only difference of the x86 CPU being replaced with a PowerPC one. Try run Word or World of Warcraft on them. It won't run. So they are not PCs.

This is a complete non-sense, since I was talking about the HARDWARE.

If it wasn't clear-enough to you (SIC!), your beloved machines BORROWED all PC (HARDWARE) technology while just replacing the x86 CPU with a PowerPC one.
Quote:

Or you just show a non-Amiga-user an AmigaOne (the GUI and everything) and ask him if this is a PC. He will look at it and say "I do not know what this is but obviously it is no PC".

Dismantling this is super easy to me:

http://www.aros.org/pictures/screenshots/20060901/arosrus.jpeg

This is AROS running on... a PC! Do you see a PC looking at it? Does the environment look familiar to you?
Quote:

Amiga was already about the operating system in late 90s.

I reveal you a secret: in late 90s there were no Amigas anymore...
Quote:

Nobody cared on the crappy custom chipset. MagicSN

Well, this is the only thing which I agree on, since Commodore died on 1994, ESCOM 2 years after, and there were no Amigas anymore after that.

Which is more or less what happens talking about your beloved PowerPCraps: nobody cares about them...


@Karlos

Quote:

Karlos wrote: @MagicSN Nobody cares what an ordinary windows user thinks a PC is. We are Amiga users of 30+ years. You won't find a bigger group of factually correct or GTFO irretrievably-far-along-the-spectrum dwellers on the interweb. I was a puritanical, nay fanatical, Amiga user until 2007. I've used AmigaOS on Amiga, Amithlon and UAE, OS4 on Amiga 1200/PPC and AmigaOne/G4, MorphOS (1.3 only), AROS on x86. Of all of these, the A1200, with all it's Frankenstein expansions, was the one that gave the most joy and the only one that ever felt "complete". To say it's all about the OS is a bit disingenuous.

I would say that it's totally false and misleading.

Which doesn't surprise me: it's clearly evident that the guy haven't read Commodore's document, so he doesn't know the definition of what an Amiga was...

@matthey

Quote:

matthey wrote: cdimauro Quote: I see two problems then. First is that the you need anyway to follow the VBCC changes and adapt your new backend as well. So, something like GCC could happen (albeit it's unlikely, since I don't see many progresses on VBCC), and rebasing each time the changes could be a nightmare. Second is the copyright: VBCC is not open and even if you create a new backend for it then you're not allowed to release products based on VBCC without a permission / agreement with the author. A new 68k backend for vbcc would need to be distributed separately from vbcc and use significantly different code so as not to violate copyrights, at least without permission. I don't think it would be difficult to get permission but there would be no guarantee a new backend would ever replace the old, even if it became overall better. A replacement would likely not be as simple, compact, have scrunched together code and have German comments. It would be possible to have English and German comments but that enlarges the code like not scrunching together the code.

OK, understood now. You want to maintain the new backend like the current machines/m68k folder and just replacing it when compiling VBCC.

That makes sense and is quite easy / straightforward.
Quote:

cdimauro Quote: Yes, but Bebbo has a more modern version and with a much better backend: AFAIR it's better than the 2.95. The only thing that I don't understand (or I simply don't know if there are some reasons) is why its changes aren't upstreamed. That would be great if Bebbo's GCC changes are "much better" than GCC 2.95.3. I haven't kept up on the project so I don't know the results but it is useful even if it can't match GCC 2.95.3 as it brings much more modern C and GCCism support. It is useful to fork source code so it can be experimented with. I would think improvements could be fed back into the active source code but there can be political resistance with GCC developers not wanting to change existing working code for an architecture with no new hardware. The GCC developers would rather kill the 68k backend and support which they tried. cdimauro Quote: The main problem is the lack of C++ support. Which is ok: C++ is a monster with big developments: it requires HUGE effort even for supporting some old version. Which, unfortunately, restricts VBCC audiance. Volker looked into supporting embedded C++ which is a subset of C++ but it never took off. https://en.wikipedia.org/wiki/Embedded_C++ Even a subset would be useful as Apple uses a different subset that avoids heavy C++ features. Maybe there wasn't enough input from developers before creating the standard.

That's interesting. Unfortunately namespaces aren't part of Embedded C++ and I don't understand why they could be seen as "complex", since it's just another way to define... namespaces.

That's one of the things which I heavily used when I've worked with Arduino (and plain classes too, without multiple inheritance).
Quote:

cdimauro Quote: Indeed and it was really fun watching the video (I already know and studied the ZCe extension): it's clear admission that RISC-V sucks at code density (20-25% worse is a HUGE difference!). It's ever more fun when I think that its great architects reserved beforehand 75% of the opcode space only for the compressed / 16-bit instructions. And they, still, failed... Anyway, this is a testament of the fact that CISC was and still is a much better macroarchitecture family compared to RISCs. BTW, here are the statistics: https://docs.google.com/spreadsheets/d/1bFMyGkuuulBXuIaMsjBINoCWoLwObr1l9h5TAWN8s7k/edit#gid=1679419155 It's evident that the biggest contributes to the code density improvements are coming from the PUSH/POP with multiple registers and the ability to call "far" subroutines. The first is an advantage that 68ks had since the beginning. The second is common for almost any CISC architecture. Again, a testament of how much better CISCs are... Good results from CISC like RISC-V extensions but they have the same problem ARM had before AArch64 which was lack of standardization. Actually, it's not even as bad as ARM was. I counted 95 RISC-V extensions. https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions The hardware configuration line when compiling will end up being several lines long. SiFive wants better standardized code density using the new compressed extensions.

LOL! I still clearly recall several years ago prof. Asanovic finger pointing x86 and ARMs for having too many extensions which produced too much fragmentation, and censing his architecture because of the few extensions that grouped instructions in a simple and clear way.

Now it's exactly the opposite, with RISC-V architects which had to introduce those myriads of Z* extensions to fix their mistakes.

Coherence and RISC-V are mutually exclusive.
Quote:

SiFive's case for retaining Zc* in RVA https://www.reddit.com/r/RISCV/comments/176g4a9/sifives_case_for_retaining_zc_in_rva/?rdt=49747 Qualcomm wants to move away from ARM with the tightening of ARM IP and the lawsuits but they want simpler decoding for their cores which were using AArch64. Wasn't RISC-V decoding supposed to be simple and the compressed extension optional?

Exactly! Actually AArch64 seems to be much simpler: a few formats used, even with around a thousand of instructions.

Anyway, I had a big pleasure when reading this (from the above document):
"Without new complex instructions, code-size penalty will hurt RISC-V adoption"

Complex... instructions? On a RISC?
@matthey

Quote:

matthey wrote: RISC-V left most of the encoding space for customization. Maybe NEx64T could be encoded into the custom encoding space since RISC-V and NEx64T both use a variable length 16 bit encoding.

No, fortunately NEx64T has nothing to do with RISC-V and its advantage is that I've better used the opcode space for its instructions (hence the results).
Quote:

Maybe a JIT acceleration extension is good enough though?

No, x86 requires much more than an hardware-accelerated JIT extensions for helping the execution of its binaries.

Apple and maybe ARM (if I recall it correctly) introduced proper instructions solely for the purpose of accelerating x86 execution. That's one of the reasons why Rosetta 2 is so fast.

@cdimauro

Quote:

cdimauro wrote: How do you think to implement SMP without drastically dropping the compatibility with the existing applications?

What are these 'existing applications' that are so desperately needed and must be preserved in their original state?

Quote:

There were plenty of them which directly accessed the o.s. structures because there was no other way to do it, as you are proud of!

Name one.

Quote:

here it's clearly that you never understood how the Amiga worked and you never have read Commodore's guidelines... That's because you were allowed to kick out the o.s. AND develop games (or anything) WITHOUT doing nasty things. It should have been enough to follow the SPECIFIC guidelines for THOSE cases. Which were reported on a couple of pages of the Amiga Hardware Manual (which you've never read it, evidently).

The Amiga Hardware Reference Manual doesn't say anything about the OS.

Kicking out the OS is nasty by definition. Since this thread is about ppc I shouldn't have to point out that hardware banging games (and apps) are off topic here.

The AmigaOS Documentation Wiki (last updated 3 October 2023) has a wonderful section on game programming. Here's what it says about Amiga Hardware:-

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: How do you think to implement SMP without drastically dropping the compatibility with the existing applications? What are these 'existing applications' that are so desperately needed and must be preserved in their original state? Quote: There were plenty of them which directly accessed the o.s. structures because there was no other way to do it, as you are proud of! Name one.

It's evident that you never used the Amiga o.s....

Here's one of the most famous ones: https://sourceforge.net/projects/scoutos/

In general, you can check any application which reportes the list of tasks, processes, windows, etc..: they NEED to access the system structures. BY definition!
Quote:

Quote: here it's clearly that you never understood how the Amiga worked and you never have read Commodore's guidelines... That's because you were allowed to kick out the o.s. AND develop games (or anything) WITHOUT doing nasty things. It should have been enough to follow the SPECIFIC guidelines for THOSE cases. Which were reported on a couple of pages of the Amiga Hardware Manual (which you've never read it, evidently). The Amiga Hardware Reference Manual doesn't say anything about the OS.

LOL You really want to show to the world that you never read the Amiga Hardware Manual. No, problem, here we go!

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0001.html
This book is intended for the following audiences:

* Assembly language programmers who need a more direct way of
interacting with the Amiga than the routines provided in the system
software.

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node000B.html
For maximum upward
compatibility, it is strongly suggested that programmers deal with the
hardware through the commands and functions provided by the Amiga
operating system.

If you find it necessary to program the hardware directly, then it is your
responsibility to write code which will work properly on various models and
configurations. Be sure to properly request and gain control of the
hardware you are manipulating

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node000D.html
If you find it necessary to program the hardware directly, then it is
your responsibility to write code that will work correctly on the
various models and configurations of the Amiga. Be sure to properly
request and gain control of the hardware resources you are
manipulating
[...]
If you are leaving the system up, do
not read or write to the CIA Interrupt Control Registers directly;
use the cia.resource/AbleICR(), and SetICR() functions. Even if you
are taking over the machine, do not assume the initial contents of
any of the CIA registers or the state of any enabled interrupts.

I've highlighted some words for YOUR convenience. And the o.s. is ALSO mentioned several times (only if you read the docs, of course!).
Quote:

Kicking out the OS is nasty by definition.

Specify: it's YOUR definition! NOT the one from Commodore, which ALLOWED it! See above, ignorant!

And read the documentation at least ONE time in your life!
Quote:

Since this thread is about ppc I shouldn't have to point out that hardware banging games (and apps) are off topic here. The AmigaOS Documentation Wiki (last updated 3 October 2023) has a wonderful section on game programming. Here's what it says about Amiga Hardware:-

LOL Now you switched to the AmigaOS4 programming, which OBVIOUSLY don't recommend doing something which with the Amiga (A-MI-GA) it was perfectly legit and Commodore ALLOWED and has shown how to properly do it (only to the people which read its documentation. Which is clearly NOT your case).

You're so desperate that you resorted "asking help" to OS4. MUHAHHAHAHAHAHHAH

I don't think anyone is seriously under the illusion that programming to the OS guidelines is not the best way to write compatible, futureproofed application software, whether that's for OS4.x or OS3.x, or indeed any operating system.

There are criticisms that can be reasonably levelled at NG as a whole - in particular the hardware choices - but if there's one thing the OS does reasonably well it's to minimise the impact of those hardware choices.

OS-compliant 68K compiled for 3.x generally runs fine on OS4 and even some degree of bitbashing too - depending on which bits anyway (you obviously get better mileage there when running on an actual Amiga).

If you don't care about compatibility beyond Amiga hardware then the Hardware Manuals have you covered.

_________________
Doing stupid things for fun...

@cdimauro

>That's obvious, but YOU made some PRECISE statements and I've "just" illustrated how is the >situation reporting FACTs.

Actually I fixed your trolling with facts. Back under your bridge.

>This is a complete non-sense, since I was talking about the HARDWARE.

If we talk on hardware, PCs use x86 hardware.

>This is AROS running on... a PC! Do you see a PC looking at it? Does the environment look >familiar to you?

Yes. But it is still AROS, not AmigaOS.

>I reveal you a secret: in late 90s there were no Amigas anymore...

Actually I used an Amiga in the late 90s and developed software for it.

MagicSN

@Karlos

But that's all I cared about since the late 90s. The OS. Else I would have left Amiga in the late 90s.

The system which gave me the most joy was the Amiga x1000.

Though I am also looking forward to receiving my "Frankenstein A1200" soon.

MagicSN

@MagicSN

Quote:

MagicSN wrote: @Karlos But that's all I cared about since the late 90s. The OS. Else I would have left Amiga in the late 90s.

I too preferred (and prefer) the OS over alternatives but it isn't able to meet the needs I have as a professional software architect, it's a hobby indulgence (which I also have very little time for). It's certainly not something that I can justify the expense of (i.e. current OS4 on vanity hardware).

Quote:

The system which gave me the most joy was the Amiga x1000.

Sure, but you must also recognise that owning an x1000 puts you in an absolutely minuscule subset of users of what is already a diminished set. Consequently what you prefer or think is right and good based on *that* experience is simply not representative of - to the extent that it's as good as irrelevant to - Amiga users in general.

I like OS4: I am not a hater. I like PPC: I am not a hater.

However, OS4 on PPC has become so stratospherically out of touch with common sense today that I just can't watch. I mean look at the Tabor thread. A machine that some people wait over a decade for to throw money at, which isn't even properly compatible with the intended PPC architecture, let alone any legacy 68K that dares to touch the FPU. Is this really the right way?

If it's all truly about the OS, then why stick to PPC? You could have OS4 recompiled on ARM big endian. Emu68 has categorically proven that performant and compatible 68K emulation is possible. If OS4 ran natively on standalone RPi 5 (and if wishfully thinking a second, PiStorm), how many more customers do you think it would have?

If you truly love the OS, why insist on attaching it to a necrotic CPU architecture that's only going to kill it off?

Quote:

Though I am also looking forward to receiving my "Frankenstein A1200" soon.

Of course you are.

Last edited by Karlos on 04-Dec-2023 at 01:08 PM.
Last edited by Karlos on 04-Dec-2023 at 01:01 PM.
Last edited by Karlos on 04-Dec-2023 at 12:57 PM.

_________________
Doing stupid things for fun...