@cdimauro

Quote:

coder76 wrote: Yes, perhaps with future iterations SAGA gets faster, this 3D demo with a single object already runs in less than 50/60 FPS according to frame time. Quote: cdimauro wrote: Because it's a simple demo. SAGA could improve, but its intrinsic limits can't be overcome. A much better FPGA is needed, but the platform is already quite expensive and then it would be out of market. The game changer would be the 68080 in ASIC, which could likely reach 1-2Ghz, but it requires a consistent investment which isn't worth only looking at the Amiga market (is should expand to the embedded market, to justify financing it).

Gunnar mentioned he tested AC68080 on some more expensive FPGA, that gave it over 200 MHz, I suppose FPGAs can become cheaper with time, and then these kind of upgrades would be possible, if ASICs cant be made. Naturally, you're not going to get the 1-2 GHz with FPGAs ever. With the 3D unit, a possibility would be to add just more 3D units that work in parallell, to improve performance, but you need then a faster CPU as well and greater memory bandwidth. I'm not an expert in this field, though.

Quote:

cdimauro wrote: Take a look at my articles, and you'll find the solutions for evolving (A LOT) the original platform, while keeping 100% backward-compatibility.

Yes, there seems to be a lot written there, I will continue to read it.

Quote:

cdimauro wrote: There are already other projects with a slightly better Amiga chipset, but Gunnar does always what he likes (which is OK: it's his project. Nothing to say here).

What sort of projects are these? I mentioned the recreation of old Amiga custom chips in FPGA, and then there are some minimig FPGA Amigas, and minimig-AGA apparently, but these are slow in performance compared to Vampire/Apollo. And not so popular, as far as I can tell.

@cdimauro

Quote:

But, out of curiosity: did you play with PowerPC assembly

Of course. It's ok, though, the therapy sessions after were really helpful!

Honestly though, I do wonder what they were smoking. Things I really hated:

- The mnemonics were and will surely continue to be the worst ever conceived by anyone/anything for any purpose in any field in the history of every sapient species in the entire cosmos, including all of it that exists beyond the observable horizon. Forever, and ever, amen.
- Reverse bit position numbering.
- Special r0 behaviours.
- Dealing with split immediates.

Things that were cool:
- Having a lot of registers
- The choice or not of updating the CC for various instructions.
- Three operand operations
- Masked shift/rotate operations
- Raw performance (relative to the 68040 I had at the time).

_________________
Doing stupid things for fun...

Actually there was one mnemonic I loved. The one to enforce in order execution output: eieio

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: Actually there was one mnemonic I loved. The one to enforce in order execution output: eieio

Is that pronounced like an astonished Italian American from New York/New Jersey:
'ey 'ey o'?!

fgtbt

_________________
All the way, with 68k

@Karlos

Quote:

Karlos wrote: @cdimauro Quote: But, out of curiosity: did you play with PowerPC assembly Of course. It's ok, though, the therapy sessions after were really helpful! Honestly though, I do wonder what they were smoking. Things I really hated: - The mnemonics were and will surely continue to be the worst ever conceived by anyone/anything for any purpose in any field in the history of every sapient species in the entire cosmos, including all of it that exists beyond the observable horizon. Forever, and ever, amen. - Reverse bit position numbering. - Special r0 behaviours. - Dealing with split immediates.

That's all your own fault. You're not supposed to be using asm. The compiler handles that stuff fine. The only time asm may be needed is when making the compiler back-end, a task assigned only to the most extreme weird people usually with Asperger's. Since normal people should never be using asm it doesn't matter if it's hard to work with.

Using asm is pointless because no human can beat the efficiency of a good compiler. It's also much more time consuming and very prone to errors that are impossible to detect reliably and therefore is a huge security risk as well as being a waste of resources. For all these reasons and more we have deliberately made the mnemonics and behavior even more inscrutable than usual to discourage fools like you from attempting to use asm. You should be thanking us for it, not complaining!

Last edited by bhabbott on 29-Apr-2025 at 02:03 AM.

@coder76

Quote:

coder76 wrote: @cdimauro Quote: cdimauro wrote: Because it's a simple demo. SAGA could improve, but its intrinsic limits can't be overcome. A much better FPGA is needed, but the platform is already quite expensive and then it would be out of market. The game changer would be the 68080 in ASIC, which could likely reach 1-2Ghz, but it requires a consistent investment which isn't worth only looking at the Amiga market (is should expand to the embedded market, to justify financing it). Gunnar mentioned he tested AC68080 on some more expensive FPGA, that gave it over 200 MHz, I suppose FPGAs can become cheaper with time, and then these kind of upgrades would be possible, if ASICs cant be made. Naturally, you're not going to get the 1-2 GHz with FPGAs ever.

Despite Moore's law (which will end soon, unfortunately), FPGAs weren't able to scale in performance and/or price like many other components.

I don't know if it's a policy of the vendors (IMO that's the reason), but that's the situation.

So, don't expect any magic coming from FPGAs. Certainly not soon, but maybe something could change in the long term.
Quote:

With the 3D unit, a possibility would be to add just more 3D units that work in parallell,

It depends on how you implement it, because two independent units cause contentions that can make disasters (e.g.: corrupted graphics).
Quote:

to improve performance, but you need then a faster CPU as well and greater memory bandwidth. I'm not an expert in this field, though.

Me neither, because I'm a developer and not a hardware engineer, but I share the same opinion.

Getting more bandwidth is possible with new FPGAs that "just" support new memories, but the main problem is using such increased bandwidth, and with a CPU running in the 100Mhz ballpark that's not possible. The CPU is the primary showstopper here, and it definitely need to go to ASIC.
Quote:

Quote: cdimauro wrote: There are already other projects with a slightly better Amiga chipset, but Gunnar does always what he likes (which is OK: it's his project. Nothing to say here). What sort of projects are these? I mentioned the recreation of old Amiga custom chips in FPGA, and then there are some minimig FPGA Amigas, and minimig-AGA apparently, but these are slow in performance compared to Vampire/Apollo. And not so popular, as far as I can tell.

Well, they were very very popular. Minimig is the most know and used/sold, but there are others like FPGA Arcade, MiST, MiSTer, Cameleon, and probably more (you can ask kolla for more details: he's THE expert here).

Some of them provide an enhanced platform, albeit not at the level of the Apollo project.

@Karlos

Quote:

Karlos wrote: @cdimauro Quote: But, out of curiosity: did you play with PowerPC assembly Of course. It's ok, though, the therapy sessions after were really helpful!

Quote:

Honestly though, I do wonder what they were smoking. Things I really hated: - The mnemonics were and will surely continue to be the worst ever conceived by anyone/anything for any purpose in any field in the history of every sapient species in the entire cosmos, including all of it that exists beyond the observable horizon. Forever, and ever, amen. - Reverse bit position numbering. - Special r0 behaviours. - Dealing with split immediates.

I share the same opinion.
Quote:

Things that were cool: - Having a lot of registers - The choice or not of updating the CC for various instructions. - Three operand operations - Masked shift/rotate operations - Raw performance (relative to the 68040 I had at the time).

Indeed.

Having removed the last one (also because there is no processor at the moment ), I implemented the others in my latest architecture.

The most impressive thing (probably the only one) which I've liked A LOT are the mask/rotate instructions! Here the IBM engineers did a GREAT job, because they not only do shifts and rotates, but bitfields as well.

Anyway, I've no bitfield instructions on my latest architecture (completely removed them), because any instruction (not the compact ones) can "become" bitfields (but paying a big price in terms of instruction size: a minimum of 8 bytes. And more, depending on the complexity / type of the requested "bitfield service").
Quote:

Karlos wrote: Actually there was one mnemonic I loved. The one to enforce in order execution output: eieio

Right. When I saw it the first time I though: it's a joke. It should be a joke!


@agami

Quote:

agami wrote: @Karlos Quote: Karlos wrote: Actually there was one mnemonic I loved. The one to enforce in order execution output: eieio Is that pronounced like an astonished Italian American from New York/New Jersey: 'ey 'ey o'?! fgtbt

It always reminds me this: https://www.youtube.com/watch?v=pSj2h34ZrmY

@bhabbott

Quote:

bhabbott wrote: @Karlos Quote: Karlos wrote: Of course. It's ok, though, the therapy sessions after were really helpful! Honestly though, I do wonder what they were smoking. Things I really hated: - The mnemonics were and will surely continue to be the worst ever conceived by anyone/anything for any purpose in any field in the history of every sapient species in the entire cosmos, including all of it that exists beyond the observable horizon. Forever, and ever, amen. - Reverse bit position numbering. - Special r0 behaviours. - Dealing with split immediates. That's all your own fault. You're not supposed to be using asm. The compiler handles that stuff fine. The only time asm may be needed is when making the compiler back-end, a task assigned only to the most extreme weird people usually with Asperger's. Since normal people should never be using asm it doesn't matter if it's hard to work with. Using asm is pointless because no human can beat the efficiency of a good compiler. It's also much more time consuming and very prone to errors that are impossible to detect reliably and therefore is a huge security risk as well as being a waste of resources. For all these reasons and more we have deliberately made the mnemonics and behavior even more inscrutable than usual to discourage fools like you from attempting to use asm. You should be thanking us for it, not complaining!

I fully agree. Real Programmers (!) don't use asm: assembly is for quiche-eaters!

We should all go back to Commodore's BASIC 2.0 (1.0 can't be found, unfortunately), because even compilers are too much: pure (token-by-token) interpreters are much better!

@bhabbott

Yeah but I probably do have "Asperger's". Though I'm high functioning enough to recognise the sarcasm wasn't directed at me ;)

_________________
Doing stupid things for fun...

@agami

Quote:

agami wrote: @Karlos Quote: Karlos wrote: Actually there was one mnemonic I loved. The one to enforce in order execution output: eieio Is that pronounced like an astonished Italian American from New York/New Jersey: 'ey 'ey o'?! fgtbt

I was thinking of an old nursery rhyme: https://youtu.be/RobT920n0qA?feature=shared

_________________
Doing stupid things for fun...

In the days when I was grappling with PPC assembler, the thought did occur that you could implement your own meta assembly language based on more familiar 68K style syntax.

There was, of course a tool that coyote flux created to do something similar, but that was more about porting existing 68K to PPC.

What I was thinking of was just a reduced mnemonic complexity with familiar things like the dot size notation and more familiar sounding mnemonics.

Of course, a significant part of the problem here is the way in which the ISA has so many variants that have specific side effects (or not) such as whether or not to update CC, zero padding loaded values and all kinds of other fruity things. If you abstract too much, you'll end up writing code that has a lot of performance defects.

It's still an intriguing idea. Maybe I'll have a go one day.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: I was thinking of an old nursery rhyme: https://youtu.be/RobT920n0qA?feature=shared

They never explain what happened to old man McDonald after he got rid of the farm. Or did he perhaps lose it in a card game and it's a sore subject.

_________________
All the way, with 68k

@Karlos

Quote:

Karlos wrote: In the days when I was grappling with PPC assembler, the thought did occur that you could implement your own meta assembly language based on more familiar 68K style syntax. There was, of course a tool that coyote flux created to do something similar, but that was more about porting existing 68K to PPC.

I had similar needs when I was reverse engineering the Pool 10 (it was around 1997) and created some modified versions.

It was based on the 65C02, but I never liked the mnemonics and, in general, the fact that it was too much low-level and primitive. So, I've designed a new, more higher-level, language which was strongly Modula-2 / Turbo Pascal inspired:

module TestEprom

  section RAM bss
    audioa = $c00; audiod = $c01; videoa = $e00; videod = $e01
    io1da = $800; io1ca = $801; io1db = $802; io1cb = $803
    io2da = $a00; io2ca = $a01; io2db = $a02; io2cb = $a03
    scrchar = $6000; scrattr = $7000

    # b_coin1
    f_coin1 = 1 shl b_coin1

    Source,Target,Length,Target2,Temp,ReturnAddress : word
    Width,Height,SpriteNum,SpriteAttr,VSync,Seconds,FuncNum,Delay,TempX,TempY : byte
    lastinput1,lastinput2,lastinputid,lastinputdipsw,
      input1,input2,inputid,inputdipsw : byte
    CurrAddr : word
    TempString = $80
  end

  section Codice code $8000,$ffff

    proc ColdReset
      reset i; x := #255; s := x; reset d
      call ResetAudio; call ResetVideo; call ClearScreen; call ResetIO
      VSync := #0; FuncNum := #0
      jump DumpMem
    end

    proc DumpMem
      CurrAddr := #0; CurrAddr + 1 := #0
:WaitVSync
      call Dump; call GetInput; a := #0; x := #0
      if reset input1[b_hold1] No_Left; dec; dec x; :No_Left
      if reset input2[b_hold2] No_Right; inc; :No_Right
      if reset input2[b_hold3] No_Up; a := #(-8); :No_Up
      if reset input1[b_hold4] No_Down; a := #8; :No_Down
      if reset input1[b_hold5] No_PageUp; a := #(-(29 * 8)); :No_PageUp
      if reset input1[b_start] No_PageDown; a := #29 * 8; :No_PageDown
      reset c; add CurrAddr; CurrAddr := a
      a := x; add CurrAddr + 1; CurrAddr + 1 := a
      jump WaitVSync

    code $fffa,0
    NMIVector : word = ColdNMI
    ResetVector : word = ColdReset
    IRQVector : word = ColdIRQ
  end
end

add! r10, [r20]+.b{z}, [r30 + r31* + 0x1234567].w

mov r10, [pc + r20* + 1234] {be}

mov r10, [pc + r20* + 1234] {big endian}

@agami

My take I that all the animals were making their noises out of order, so eieio was necessary to ensure they were sounded out in the correct sequence dictated by their introduction. It's what eieio is for.

_________________
Doing stupid things for fun...

@cdimauro

That's an interesting approach. In my head I was thinking 68K style but keeping it as a load/store, so there's never any kind of effective address arguments (aside from immediates) for instructions that aren't data move.

I can see the extended meta being useful, perhaps as some kind of OR-able flags

move.w 8(r13),r3,ZERO_PAD
add.l r3,r4,r3,NO_CC

Just thinking aloud

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro That's an interesting approach. In my head I was thinking 68K style but keeping it as a load/store, so there's never any kind of effective address arguments (aside from immediates) for instructions that aren't data move.

68k is my reference / benchmark, but I'm trying to creating something which is more readable / usable. Which, in my case, is also a need, because of the additional features that I expose to the developers.
Quote:

I can see the extended meta being useful, perhaps as some kind of OR-able flags move.w 8(r13),r3,ZERO_PAD add.l r3,r4,r3,NO_CC Just thinking aloud

Thanks.

Yes, the mechanism allows to "or" such flags, but using a math-style set. For example:

mov r10, [r20].w {z, be}

add{no flags, non-temporal} r10, [r20]+.b{z}, [r30 + r31* + 0x1234567].w

@all
Sorry, I was distracted but will give a few answers in catch up.

Kronos Quote:

So markets/products that were low end 20-30 years ago and haven't till now not seen the need for an HW upgrade? Yeah, those are gonna jump on an untested new chip from a dubious company and off course they will be paying top $ for the privilege. Might have worked 20 years ago.

The hobbyist and retro market sales would be relatively large at first and then taper off with seasonal and cyclical demand variations. Embedded market demand would likely start slower and ramp slower but provide more defensive consistency. The combined markets allow lower profit margins to be safer as the RPi has demonstrated and Commodore wished they had had when the PC market crashed in the early 1990s.

The slow replacement of existing big endian 68k, ColdFire and SuperH hardware for embedded industrial use continues. The 68000 is still available from NXP for original replacements but the silicon is old, performance low, SoCs are lacking and EOL discourages use.

https://www.nxp.com/products/MC68000

ColdFire and 68k/CPU32 CPUs are still available but other 68k CPUs are not.

https://www.nxp.com/products/processors-and-microcontrollers/legacy-mpu-mcus/32-bit-coldfire-mcus-mpus:PC68KCF#m680x0

Still, not everyone converts to little endian ARM. Another 68k/CPU32 option is available from Intel.

https://www.intel.com/content/www/us/en/partner/showcase/offering/a5b3b0000000ynQAAQ/d68000cpu32--1632bit-microprocessor.html Quote:

D68000-CPU32 - 16/32-bit Microprocessor About this offer The D68000-CPU32 soft core is binary-compatible with the industry standard 68000’s CPU32 version of the 32-bit microcontroller. The D68000-CPU32 has a 16-bit data bus and 24-bit address data bus. It is code compatible with the MC68008, MC68010 and CPU32 (version of MC68020). The D68000-CPU32 has an improved instructions set, which allows program execution with higher performance than the standard 68000 core. It contains a built-in DoCD-BDM debugger interface. The D68000-CPU32 is delivered with fully automated test bench and complete set of tests, allowing easy package validation at each stage of SoC design flow. Details Use Case Environmental Monitoring Energy Monitoring Digital Security Surveillance Print Imaging and Office Automation Smart Building Digital Signage Factory Automation Industry Energy and Utilities Health and Life Sciences Manufacturing Automotive Communications Defense and Space

There is the industrial embedded use mentioned where the 68k, ColdFire and SuperH were so popular. Some replacements are likely a "soft core" like D68k cores used in FPGAs and potentially ASICs too.

https://www.dcd.pl/product/d68000-cpu32-2/ Quote:

The D68000-CPU32 soft core is binary-compatible with the industry standard 68000’s CPU32 version of the 32-bit microcontroller. The D68000-CPU32 has a 16-bit data bus and a 24-bit address data bus. It is code compatible with the 68000’s CPU32 (version of MC68020). The D68000-CPU32 has an improved instruction set, which allows program execution with higher performance than the standard 68000 core. It contains a built-in DoCD-BDM debugger interface. The D68000-CPU32 is delivered with a fully automated test bench and a complete set of tests, allowing easy package validation at each stage of the SoC design flow. ... Fully synthesizable, static synchronous design with no internal tri-states

The higher cost of FPGAs can be partially offset by the ability to create a SoC in FPGA, at least when the SoC area is small enough and performance and low power are less important. Motorola used to offer a SCM68000 soft core for SoCs all the way back in 1995.

EC000 Core Processor (SCM68000) User’s Manual
https://www.nxp.com/docs/en/reference-manual/EC000UM.pdf Quote:

1.1 FLEXCORE INTEGRATED PROCESSORS FlexCore allows designers of high-volume digital systems and third-party technology providers to place their proprietary circuitry on chip with a Motorola microprocessor. By using FlexCore, a designer can reduce the total system cost, component count, and power consumption while providing higher performance and greater reliability. Up to 100,000 gates or more of custom logic, memory, and peripheral modules can be added to a core processor to produce the most cost-effective solution for a designer's system. The core processors provide special power-management features such as 5 V, 3.3 V, and static operation. The 68000 Family of core processors offers the designer a range of performance from 3 to 12 million instructions per second (MIPS) (to be extended to 100 MIPS) while maintaining complete code compatibility throughout the Family. The 68000 processors have a proven architecture with a broad base of application and system software support, including real-time kernels, operating systems, and compilers, in addition to a wide range of tools to support software development. In the future, additional processing architectures will be included in the FlexCore program, including PowerPC and digital signal processing (DSP). Figure 1- 1 shows a typical die layout for a FlexCore integrated processor.

This was a la carte SoC development offered by Motorola for the 68k in 1995. Commodore was planning a 68k Amiga SoC a little before this but unfortunately committed financial suicide first. It appears Motorola and successors moved away from this ARM like business model. NXP only goes after the big fish and the 68k is likely long forgotten. There may still be a market for it as the D68k shows but it is likely a shrinking market without a large player supporting it and a better range of 68k products.

bhabbott Quote:

The Raspberry Pi uses a Broadcom BCM2835 SoC designed for multimedia devices. The CPU inside it is largely irrelevant - all the other stuff is what matters. The Raspberry Pi foundation figured it could be used to make a small low cost computing computing device for the education/hobbyist market - like Arduino but much more powerful. They managed to convince Broadcom to sell chips to them, and the rest is history.

An affordable "multimedia device" sounds like the 68k Amiga. Granted, the 68k Amiga was not a SoC yet which was not possible when released. It was possible and planned by Commodore in the 1990s which would have lowered the cost, improved performance and reduced power with the planned CMOS instead of NMOS design. Jay Miner understood the importance of integration which he used to bring the Amiga to market while Commodore did not. Later embedded hardware after the Amiga resembled the Amiga and some copied the Amiga chipset. With further integration, the 68k Amiga may have become what the RPi is today but possibly up to a decade earlier.

bhabbott Quote:

Could a similar chip with embedded 68k CPU be better for us? Sure, but that doesn't exist and won't exist because there isn't a big enough market for it. Nobody (apart from fans of retro 68k machines) is interested in a 68k SoC because there are already other chips that do the job. The Pi 5 now has a 2.4 GHz quad-core 64-bit ARM Cortex-A76 CPU and VideoCore VII GPU making it twice as powerful as the Pi 4. Pi users aren't wanting for performance. 68k is completely irrelevant to the embedded world.

The Sega Genesis Mini alone has sold over 1.5 million units which does not include the Sega Genesis Mini 2, FPGA devices or RPi emulation hardware.

https://gamerant.com/sega-genesis-mini-2-low-limited-supply/ Quote:

According to sales data, the 2019 original Sega Genesis Mini (or Sega Mega Drive Mini depending on the region) sold over 1.5 million units. Some consoles even had region exclusive games depending on where they were sold. Much like the original, the Sega Genesis Mini 2 has a number of retro titles, although this time will feature some classics that never made it onto the system as well as some Sega CD games. Despite this being a product that would be greatly anticipated by older Sega fans and prospective buyers, the mini console will be in less supply compared to its 2019 release.

THEA500 Mini has likely sold at least 100,000 units with many handicaps like no AmigaOS, non-functional keyboard, minimal I/O, least accurate emulation, etc. Despite THEA1200 Maxi higher price, it may outsell THEA500 Mini due to much better value from less handicaps. A 68k SoC could make THEA1200 cheaper than THEA500 Mini while removing practically all handicaps.

There is the Neo Geo, X68000, Atari 68k, Mac 68k, Linux/Unix/BSD 68k, NeXT, Sinclair QL, etc. The 68k market is no doubt in the millions but it is difficult to judge the full potential as most hardware has used poor emulation and/or has been expensive. RPi emulation of the 68k is likely the largest single beneficiary of crap 68k hardware.

bhabbott Quote:

Cross-developing on a 'modern' PC has numerous advantages. You can use inefficient tools that would run far too slow on original Amiga hardware, in a more comfortable environment. You can debug your code in an Emulator which provides more insight into what the hardware is doing. I have done this for the Amstrad CPC and Mattel Aquarius and it was great. However I enjoy developing stuff on my A1200 just like I used to in the 90's, so it enhances the retro experience whereas doing it on a PC wouldn't.

I understand the advantages of cross compiling on more powerful hardware. Doom was developed on a NeXT 68k workstation rather than a limited x86 PC for example. I also prefer to develop on the 68k Amiga and more powerful 68k Amiga hardware would allow more of it even if large projects with bloated compilers need serious performance.

bhabbott Quote:

68k Amiga hardware isn't going extinct. It is getting more expensive as hoarders collect more than they need, but eventually they will die or move on and their hoards will be released. Meanwhile replacement hardware is being manufactured - just need the price of original hardware to increase a bit more to make it viable. What we need now are replacement custom chips, as most of the spares seem to have been hoovered up. Or do we? I am quite happy with the Amigas I have now. I passed over several opportunities to acquire other models because I knew they wouldn't get used. What's really going extinct isn't Amiga hardware, it's us.

We are going extinct faster than the hardware because we, Amiga users, are not proliferating the Amiga to the next generation of Amiga users. Most Amigas will likely end up in dumpsters as appreciation for the Amiga dies with us and prices start to decline. Much better and cheaper hardware is needed to attract the next generation of users. Most Amiga users do not want to use a 68000 OCS Amiga either but want upgraded and enhanced 68k Amiga hardware. Further upgrades beyond a 68060@100MHz, AA, 2MiB mem, IDE, etc., would be good like 68060@1-2GHz, AA+, 2GiB mem, HDMI, USB, NVMe/SATA drives, etc. These are similar to RPi SBC specs priced under $100 USD. Jay Miner did not say stop integrating and live in the past. He complained about Commodore not integrating and enhancing his creation and not integrating and enhancing it fast enough. You want to be a dinosaur choosing extinction with Commodore while Jay tried to avoid dinosaur extinction.

Karlos Quote:

Of course. It's ok, though, the therapy sessions after were really helpful! Honestly though, I do wonder what they were smoking. Things I really hated: - The mnemonics were and will surely continue to be the worst ever conceived by anyone/anything for any purpose in any field in the history of every sapient species in the entire cosmos, including all of it that exists beyond the observable horizon. Forever, and ever, amen. - Reverse bit position numbering. - Special r0 behaviours. - Dealing with split immediates.

I think you missed a few "I do wonder what they were smoking" PPC ideas.

- stack accesses require static sized stack frame entry for every function (dynamic variables, recursion, variable length array fun)
- lack of standardization means function prologues/epilogues even though PPC has load/store multiple

@matthey

Well, having a large set of volatile registers usually meant I could get away with not using the stack. When I did have to, I used the prolog/epilog directives like the next guy.

Also, I have to say, I think there's a germ of truth in bhabbot's satire - all these nuisances are there for the compiler to deal with so that that the chip itself can have simpler more uniform instruction decoding etc. Which was pretty much the point of RISC.

Last edited by Karlos on 01-May-2025 at 08:14 AM.

_________________
Doing stupid things for fun...

Karlos Quote:

Well, having a large set of volatile registers usually meant I could get away with not using the stack. When I did have to, I used the prolog/epilog directives like the next guy.

The PPC SysV ABI designates r0 and r3-r12 as volatile. The r0 register has special behavior as you pointed out and r3-r10 are used by function args which turn into variables. Load/store requires a free register for loads so maybe 9-10 volatile registers for local variables before having to create a stack frame for the function. Not too bad with shallow functions for code sharing like the 68k Amiga uses but calling another function uses the stack, requires a new stack frame and likely requires a new function prolog and epilog. The PPC ISA very much encourages deep functions with lots of function inlining to minimize the stack frame and prolog/epilog overhead. The deep functions are generally good for performance but it is poor for human readability, code sharing, code density and stack usage/waste. In other words, it is not good for a small footprint system like the 68k Amiga was created to be out of necessity and remains a major advantage of the 68k Amiga. Some of the performance lost by shallower functions is regained by better cache efficiency. It is important to minimize the overhead of BSR/JSR/RTS, PC relative instructions/addressing and cache accesses for such a system. The 68060 demonstrates that performance is not compromised even though a hardware link stack, indirect branch prediction, PC relative addressing in either OEP, a shorter (d32,PC) addressing mode, etc. would improve code sharing and performance.

Karlos Quote:

Also, I have to say, I think there's a germ of truth in bhabbot's satire - all these nuisances are there for the compiler to deal with so that that the chip itself can have simpler more uniform instruction decoding etc. Which was pretty much the point of RISC.

There is usually logic why each choice was made. There is also logic why each bad choice should have been tested and discarded before ISA release. Humans are usually the testers that give feedback and RISC was designed to eliminate the low level programmer with hardware simplification providing a performance advantage for high level languages. Sometimes logic fails, especially when removing the feedback mechanism. Compilers were supposed to win the battle for RISC with simplified hardware but lost the battle to CISC which used more complex but higher performance hardware and assembly programmers optimizing code.

Last edited by matthey on 01-May-2025 at 04:22 PM.