@Hypex

Quote:

Hypex wrote: @matthey I don't think it would fit either. With base 16 bit for each instruction code it isn't designed for anything else.

68k ha 32-bit opcodes as well...
Quote:

The 68K series supports "parameters" but the standard is 8 data/8 address/8 FPU. Possibly 8 vectors can fit

8 vector registers is too little.
Quote:

but they need to fit in the encoding and the Apollo has it somewhere.

There were some bits that were used for the SIMD (not Vector) unit. That's in F-line, of course.
Quote:

But, they must be extra 16 bit codes, after the main code. They cannot be prefixes like on x86. 68K is not x86 nor 68x or K86. Adding prefixes of any size to 68K is wrong. If BigGun has taken his Intel ideas and coded them that way it would be wrong.

AFAIR prefixes were not used for the SIMD unit, but only for extending the regular 68k instructions.
Quote:

That is not in the standard.

Who defines the standard(s)? Do you know that prefixes are being proposed for the PowerPC ISA?
Quote:

No need to mock the 68K with such a abomination.

I agree... if there are some other solutions.

And there are other solutions, of course: see below.

BTW, you don't necessarily need to introduce a new execution mode for enabling new features. On my ISA I've opted for bigger opcodes, to completely avoid using prefixes.


@matthey

Quote:

matthey wrote: For a 16 bit reg-mem instruction, 8 registers and 2 op instructions are the limit. With a 32 bit reg-mem instruction, 16 registers and 3 op instructions are possible (68k FPU instructions are 32 bits).

68k FPU has 32-bit opcodes, but you can define 3 operands only by using registers (so, not referencing memory) and only with your extension. When referencing memory it can only use two operands (so, the destination must also be used as second source operand).

This means that using 3 operands the FPU is working like many other architectures, but with the big limit of using only 8 registers.

However there's a lot of space for adding another 8, which is good for the 68k, which is a great CISC.
Quote:

It is possible to add a 16 bit prefix to access more registers and allow 3 op instructions. It normally isn't so bad if code mostly uses the lower registers which offer better code density. The x86-64 ISA uses a pre-fix to access the upper 8 of 16 GP registers resulting in a decline of code density. A 68k pre-fix adds an extra 16 bits but the 68k already has 16 registers and 16 more registers would be available as well as 3 op and even leaving a few more bits available.

Yes, mixing regular instructions and new/prefixed instructions only when needed might mitigate the impact on code density.

That's also how x64 is trying (limiting the use of the new REX prefix), but with scarse results...
Quote:

16 bit prefix 1 bit - high bit of source register 1 bit - high bit of destination register 1 bit - high bit of index register (may be avoidable by adding bit to full format extension) 4 bits - 3 op 2nd source register Other potential options 1 bit - CC toggle 1 bit - saturation toggle 1 bit - SIMD toggle 1 bit - 64 bit operation datatype size I believe the AC68080 uses a pre-fix like this

Exactly.
Quote:

with a 64 bit operation datatype size bit which I really don't like as 64 bit operations are common on a fully utilized 64 bit CPU greatly reducing code density, overriding the instruction size and length is bad for decoding and address register operations are already auto extended to 64 bit if following current 68k behavior.

I absolutely agree: that was a completely wrong decision: the default data size should be 64 bit on the ISA.

That's what AMD did with x64. It's simply and purely obvious (albeit not for everybody).
Quote:

It may be better to have a separate 64 bit mode where size=byte, word, long or quad after cleaning up the encodings. This is natural and efficient as Gunnar wanted and even tried to do this but it is not compatible.

I agree.

However and what people don't understand is that a 64 bit mode is anyway backward-incompatible with the 32-bit mode! So, sticking with the same opcode formats is a complete non-sense if you already know that there are big issues / challenges with it.

Keep the old 32 bit mode as it is and create a new 64 bit mode taking the good parts. Like ARM did with its AArch64. And like AMD did NOT with x64, unfortunately (which is another horrible patch on x86).
Quote:

A 68k32 high compatibility mode and 68k64 new mode likely uses more transistors and requires more design work so was rejected by Gunnar.

Which isn't a surprise...

@matthey

Quote:

A high end Amiga should be using a full 68040 with MMU at that time not that there was a high end Amiga during the 68040 and 68060 era due to the gimped low end Amiga chipset. I was referring to low end hardware for the masses like an intermediate upgrade for the CD32+ between a 68EC030 and 68040.

That's fine for the masses. But what were developers using to code and test their products? A common problem was bad coding practices and hacking into OS structures rather than code cleanly and leave it alone.

Quote:

No doubt multiply is more difficult than add to detect overflow. The ColdFire RISC castration just cut off all the upper 32 bits including overflow detection. Higher end 32 bit RISC cores have a MUL and MULH at least although two 2-5 cycle multiplies often have to be performed for 32x32=64 to avoid the hardware complexity of writing results to 2 registers.

I was reading up on the 68000 doing multiply somewhere. It was asked how it was done and a comment was made that it looped around and added the multiplicand up until the multiplier reached zero. Sounds CPU intensive. Another comment described it as shifts and adds. I actually wrote a custom multiplier years ago just experimenting that multiplied by shifting and adding 32 bits.

Quote:

Not likely. The 6800 is an accumulator architecture which is closer to the opposite of RISC in some ways, perhaps more so than CISC.

It was accumulator. In fact it had two. With an instruction count of 72 it would already have less instructions than the average RISC later on.

The 6502 looks like a poor mans 6800. With code similar to 6800. However the 6800 only one X index register thought it does have stack register SP. The copy example below looks more complex than it need be. On 6502 it would be simple load/store decrement/ loop. Perhaps it's made too complimented by forcing variables over registers. No wonder Peddle left!

Quote:

The Motorola 88000 borrowed from the 68k. ColdFire borrowed heavily from the 68k. MCore was "microRISC" that did not borrow much from the 68k and failed miserably.

The 88K was meant to be the 68K RISC follow up. A clean break unlike the ColdFire bastardisation. I don't know much about the MCore.

Quote:

PPC performance improved when maximizing the L1 caches like upgrading to 32kiB I+D L1 caches in the 604e. The shallow pipelines and slower access times of larger caches held PPC back until the on chip L2 cache became practical and PPC had a 2nd wind with the G3 and G4. PPC has always been cache hungry.

The PPC always had an issue with caches. This was said to be why x86 easily outperformed it. Because of the massive caches. Which PPC lacked because it supposedly didn't need it to be an efficient performer. But, it got left behind. The design didn't save it.

Quote:

IBM used CodePack and Motorola/Freescale VLE for code compression. Lack of standardized hardware played a part in killing PPC.

Yes I recall that now. Kind of like of a FLAC for PPC or a PPC LZMA XZ filter. . So hardware decompression on the fly from memory to cache. Not technically a VLE instruction set. Wouldn't want to run self modifying code on that beast!

This is the kind of idea I have for an x86/64 chip that can run PPC code. Just need a PPC to x86 translator. It would be singular to variable size decoding. So far have seen no designs for it from AMD or Intel. If they did that they would surely kill off Power in the server market. Maybe Power 10 is aiming too high but they could surely simulate Power 5 or 6 with such an approach at blistering speed. Internally it be going from a RISC to a CISC to a RISC core but there isn't much choice when the brute force method is the cheapest. PPC was merged with x86 in an early design chip.

Quote:

PPC has all those GP registers so compilers can unroll loops and inline functions. Every variable needs to be pre-loaded into registers for RISC to have good performance and this means spilling non-volatile registers to gain more registers. AmigaOS 4 needing in the order of ten times the stack space says something about the increased memory traffic to and from the PPC stack frame.

This was usual for tight 68K loops and operations as well. To pre-load registers. A simple 68K branch will only stack a long word. On PPC, unless the frame is optimised away, it's 16 bytes minimum, which is four fold. Save registers and then it's worse. It can save space by not stacking FP and vectors when not used. But it all needs 16 byte alignment from the convention. Being OS4 follows standard ABI conventions means the stack would bloat and OS would need more memory.

Quote:

Hollywood executables may contain more data than code.

That's likely true given it's all embedded in one binary.

Quote:

The 68k has efficient branch support which starts with small displacements for good code density but scales up to cover the whole 32 bit address range. Immediates are handled efficiently like this too. RISC ISAs have been slow to adapt even with variable length ISAs as Thumb and RVC don't take full advantage. Only BA2 and the load/store ISA Mitch Alsup was working on take full advantage that I am aware of.

It looks like most RISC attempts at 16 bit encodings are based mostly on code compression. In some attempt to reverse the 32 bit rigid trend. Without introducing a full on new hybrid ISA. BA2 looks closest to offering CISC code density.

Quote:

AmigaOS 4 may retain more of the 68k AmigaOS design and feel than MorphOS or AROS for better or for worse. I don't know if this is due to being more closely derived from it or a deliberate design philosophy. Perhaps it is some of both. Hypex Quote:

Well, they stayed close to it and retained most of the structures. In fact in some places a bit too close. Most alignment is at word boundaries so not efficient for PPC. It uses the same process locking methods for data protection. Even the emulated 68K interrupts run like native interrupts in super mode which I thought was too far. This is said to be for 68K compatibility. But since 68K is still emulated no matter what there could have been a level of separation. There are changes like some lists hidden while public locations remain as blanks.

Quote:

I expect many other Amiga users would have liked to have Amiga chipset compatibility on their RTG PCI cards so they didn't have to switch video outputs. The original Cybervision card has Amiga video passthrough which was more convenient making these cards very desirable today. There was no other choice for high end graphics as C= kept the Amiga chipset low end to turn the Amiga into the next C64 instead of the Next NeXT.

Having a CyberVision I can agree. While it does need the native video passed in as an input it does switch on demand. I used a PicassoIV until the RTG stopped working. The flicker fixer still worked so routed it through the CV.

What they needed which was only be added for AAA was a merging of RTG into the chipset. Which was in the plans for new packed modes. As well as extending the planar modes further for some reason. That or an idea like mine to extend the pixel width across one bitplane. The only issue with integrating with the existing is the latency chip ram had on the system if it wasn't improved.

Quote:

There is no ground breaking jaw dropping advancements in computers anymore. There is only more performance or a cheaper price for the existing technology. Features vary enough to allow for favorite computer environments while compatibility and software availability plays a key role in adoption.

Things have reached a plateau. 3d hardware slowly advances and resolution increases with increased memory. CPUs gain optimisations for speed along with increased clock rates and cores. Memory rates slowly increase. There is a gradual increase in power over time but perhaps things have become so good to the point there's not much that can be advanced.

Some exceptions would be quantum computers. Though they would lack Windows compatibility at present which may hold them back from a large software base. And AI is the current trend. Though it can use GPUs for hardware acceleration. So right now it would be different ways to run software and process data. Over the traditional CPU, graphic and sound increases of power.

Quote:

AmigaOS 4 has good gfx card support but...

1. Politics. Up until around OS4.1/FE it was built in. Later it was an add on. While I don't think the user cares about who provides it I think the user does want an all in one solution without needing to hunt down needed drivers themselves.

2. Since the A1222 is yet to be released to the public does it matter? Lol. Since Apple took desktop PPC away standards declined after the G4 so only embedded was left. Apart from the PA6T but that wasn't to last as Apple took that away as well. That leaves the X5000. With the X1000 forgotten about the X5000 remains as the top contender. But without SIMD support.

3. It's been going downhill for a while. From my perspective the X1000 was the last board that was reasonably power enough while not being overly expensive. Unfortunately it now looks bad against other PPC hardware.

Quote:

Poor quality Linux gfx card drivers are a major problem for ARM and RISC-V desktop systems. PCIe cards for the RPi 4 and 5 were a joke with all but one or two not working. Similar problems likely affect the RISC-V SiFive boards. Using integrated graphics allows for cheaper standard hardware thus avoiding the problem but SiFive doesn't have an open hardware GPU where open hardware is one of their selling points.

I would have imagined them having good support or better than on PPC since they are kept updated and don't have endian issues on little endian. I saw some video on the Raptor Power server with a gfx card. It had no trouble supporting it. Unlike big endian builds of PPC Linux with poor support for anything beyond the HD series. Even for PPC Linux builds back in the day there are guides for broken video on Macs making it look too common.

Quote:

For a 16 bit reg-mem instruction, 8 registers and 2 op instructions are the limit. With a 32 bit reg-mem instruction, 16 registers and 3 op instructions are possible (68k FPU instructions are 32 bits). It is possible to add a 16 bit prefix to access more registers and allow 3 op instructions. It normally isn't so bad if code mostly uses the lower registers which offer better code density. The x86-64 ISA uses a pre-fix to access the upper 8 of 16 GP registers resulting in a decline of code density. A 68k pre-fix adds an extra 16 bits but the 68k already has 16 registers and 16 more registers would be available as well as 3 op and even leaving a few more bits available.

The way 68K worked and in later models such as with 68020+ and CPU32 is it used postfixes. So a variable opcode with VLE. Opcode with extension codes as well as data.

Quote:

I believe the AC68080 uses a pre-fix like this with a 64 bit operation datatype size bit which I really don't like as 64 bit operations are common on a fully utilized 64 bit CPU greatly reducing code density, overriding the instruction size and length is bad for decoding and address register operations are already auto extended to 64 bit if following current 68k behavior. It may be better to have a separate 64 bit mode where size=byte, word, long or quad after cleaning up the encodings. This is natural and efficient as Gunnar wanted and even tried to do this but it is not compatible. A 68k32 high compatibility mode and 68k64 new mode likely uses more transistors and requires more design work so was rejected by Gunnar.

I wouldn't like that either as using a prefix for 68K encodings would be wrong.

An issue may be in the encoding of MOVE, as once example with size. The front nibble is 00SS with size. But SS is only 1 to 3. A logical progression to use 0 as quad. But ORI also uses 0000. However, MOVEP also uses 0000. The coding differs later in the opcode.

Now if the basic opcodes can fit a 64 bit op into 16 bits that can be built on. But, there are also 64 bit extensions to complicate it, such as DIVU/DIVS where the 64 bit wide data is split into register pairs. These would all need extending to wide registers. A possibility is 32 bit opcode which would impact code density. But the penalty wouldn't be as bad as RISC for wide data since all 64-bit size data words can be packed with a 32-bit sized opcode.

@cdimauro

Quote:

68k ha 32-bit opcodes as well...

With VLE it would yes. AFAIK the encoding is base 16 bit, that is 16 bit based so all codes are multiples of 16 bits, plus any data.

Quote:

8 vector registers is too little.

That's too bad as the core design has 8 each for address, data or floats. Though, given address and data combined would make 16 GPRs, perhaps encoding could offer 16 vectors. It's likely an SIMD extension would logically extend opcodes.

Quote:

There were some bits that were used for the SIMD (not Vector) unit. That's in F-line, of course.

F-line, with it's friend A-line, popular for extensions. And being F for Floating point. Perhaps it started with F-it, we need more space.

Quote:

AFAIR prefixes were not used for the SIMD unit, but only for extending the regular 68k instructions.

They wouldn't be regular after.

Quote:

Who defines the standard(s)? Do you know that prefixes are being proposed for the PowerPC ISA?

Whoever designed the 68K encoding scheme. It would use postfixes though really it's not exactly fixing it. It's more like parameters or operameters. But also, prefix suits x86/x64 because it's little endian, so prefixing a byte is natural. 68K is big endian, which really only affects byte ordering, but VLE is opcode first followed by any operand extension.

Quote:

agree... if there are some other solutions. And there are other solutions, of course: see below. BTW, you don't necessarily need to introduce a new execution mode for enabling new features. On my ISA I've opted for bigger opcodes, to completely avoid using prefixes.

As would be natural for any CISC design. But of course, with hindsight, it gives you an opportunity to redesign. If only the industry wasn't tied to existing designs, which seems ironic, because computer technology is always changing and previous methods become obsolete.

@matthey

Quote:

You mean its difficult to beat the RISC-V promotion and propaganda? Other than SuperH having a small advantage in code density, RV32IMC has better performance metrics despite being weak.

When compared to SuperH, RISC V has large corporate inertia and is mostly used for single-purpose embedded devices.

My GTX/RTX GPUs (GTX 1660S, RTX 3080 Ti, RTX 4080, and RTX 4090) have NVIDIA's custom RISC V. I sold my RTX 2080 and 2080 Ti.

Beyond 32-bit SH-2, SuperH is still a close source.

The SH-4 was used for walled garden Sega's Dreamcast and NAOMI game systems.

SuperH is useless for Amiga Retro.

Support for SH-5 was dropped from GCC and Linux.


Quote:

There is no ground breaking jaw dropping advancements in computers anymore. There is only more performance or a cheaper price for the existing technology. Features vary enough to allow for favorite computer environments while compatibility and software availability plays a key role in adoption.

For graphics, it's hardware-accelerated raytracing and AI denoiser, but hardware-accelerated raytracing doesn't solve artwork quality, story, and gameplay design.

Pixel-level geometry detail and subpixel culling can be done with mesh shaders, but this has artwork quality factors.

Both AMD and NVIDIA's recent GPUs have large on-board caches since the usual mainstream GDDR6 from Micron, Samsung, and Hynix have slower technology evolution.

HBM path is not mainstream, hence it didn't replace GDDR6 and GDDR6X.

Apple reuses LPDDR5 in a very wide topology for high memory bandwidth.

Last edited by Hammer on 28-Nov-2023 at 03:25 AM.
Last edited by Hammer on 28-Nov-2023 at 03:22 AM.
Last edited by Hammer on 28-Nov-2023 at 03:18 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hypex

Quote:

Some are so old like my XE that they are retro now. My X1000 is now over ten years old and for OS4 at least can still power it. And on the XE back then. It can play WB games. And OS friendly games to an extent. And I did enjoy seeing what would work. Sure you could do that with UAE. But there was a novelty in the early days of a native PPC AmigaOS running completely on RTG and seeing what Amiga gamed worked.

As an example, AmigaOS 4.1 on classic Amiga hardware with Phase 5 PPC couldn't fully run WB-friendly 68K Deluxe Music 2.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

The x86-64 ISA uses a pre-fix to access the upper 8 of 16 GP registers resulting in a decline of code density.

The main purpose of x86-64 is the ability to access larger memory storage without PAE36's memory segmentation. If there is a low memory storage requirement, then stay with IA-32.

x86-64's Long Mode has a larger memory address range and register expansion. Legacy IA-32 is maintained as is.


When the 32-bit x86 extension came out, there were a lot of empty spaces available in the opcode space, therefore Intel chose a free byte that hadn’t been used in 16-bit mode to indicate 32-bit registers. Hence in 16-bit mode, if the CPU sees those bytes it knows that they’re 32-bit instructions and never mistreats them as 16-bit ones.

But decades later, thousands more instructions have been added and the opcode space has been filled completely. To introduce 64-bit extension some new way to encode the 64-bit instructions have to be chosen. AMD decided that they’ll remove rarely used instructions or legacy instructions that are not used at all to free up some space. Moreover, they increased the number of registers from 8 to 16, which needs some more bits to encode.

Among the removed instructions, DEC and INC are not as useful as before in modern architecture. They’re all in 0x4X format, so they are used as REX prefixes for extra bits of the register encoding and selecting between 32 or 64-bit registers.

Later to double the number of registers to 32 in AVX-512 and add some features like 3-operand instructions another encoding has to be invented that uses the VEX prefix.

The x86-64 instruction set reuses the opcodes for single-byte INC and DEC in x86 as REX prefix, therefore it’s impossible to have 64-bit instructions in 32-bit mode and it’s also impossible to have single-byte INC/DEC in x86-64.

Last edited by Hammer on 28-Nov-2023 at 03:25 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

As an example, AmigaOS 4.1 on classic Amiga hardware with Phase 5 PPC couldn't fully run WB-friendly 68K Deluxe Music 2.

I tried DPaint back in the day but don't think I tried DMusic. I had it on a demo disk and it was one of the early OS2 programs using gadtools. I recall it included a gadtools13.library which was back ported to OS1.3 for compatibility.

Should try it out. It really depends what it's doing. I would expect DMusic would use audio.device. But don't know what else it could be poking in. For example, in the late 80's accessing Screen->BitMap was fine, but the decade after they recommended against directly accessing it since it was fixed. However, I found recently the the AHI audio.device is broken. The lock command doesn't work correctly. In fact it doesn't work at all and just returns. So that could produce faulty behaviour. The Wiki does not mention it is broken. Given it's a standard audio device command I don't consider it relevant that it isn't supported. What is relevant is that it violates the API and is therefore broken and buggy regardless. Just my negative 2 cents.

@Hammer

Quote:

As an example, AmigaOS 4.1 on classic Amiga hardware with Phase 5 PPC couldn't fully run WB-friendly 68K Deluxe Music 2.

That’s strange it does start on AmigaOS4.1 with NallePuh, a real Amiga should be more compatible than computer running with chipset software emulator. However, there is crash that’s cause by some kind of memory corruption issue. But sadly, we do not have the source code and can’t investigate what actually happens. Without a huge amount of time wasted on decompiling and reverse engineering, that’s is not going to happen. Run it in EUAE if you must run it.

We know there compatibility issues between AmigaOS4.1 and Kickstart 1.2. that also true for Kickstart 3.1/3.0 as well, also not 100% compatible with Kickstart 1.2, this way games are packed in WHDLoad, to run games with the kickstart they were designed for.

Back in the day I remember having Relokick 1.3 on a floppy disk.

Last edited by NutsAboutAmiga on 28-Nov-2023 at 04:53 PM.
Last edited by NutsAboutAmiga on 28-Nov-2023 at 04:52 PM.

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

@Hypex

Quote:

in the late 80's accessing Screen->BitMap was fine, but the decade after they recommended against directly accessing it

Not sure that apply to 68K software using fake planar screens.

Quote:

I found recently the the AHI audio.device is broken. The lock command doesn't work correctly. In fact it doesn't work at all and just returns.

that can explain some of the problems we are seeing.

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

@NutsAboutAmiga

Quote:

Not sure that apply to 68K software using fake planar screens.

Well, that would worse, since those modes were the wrong size. At the time it was just 68K and real planar. But it was also considering RTG as well since it was for expansion, the problem being the BitMap was static embedded, over a BitMap pointer which the RastPort had.

Quote:

that can explain some of the problems we are seeing.

Yes, I only discovered it last year IIRC. When I was experimenting with audio.device and found inconsistent behaviour. It was driving me nuts and I thought I had coded something wrong but just couldn't see it.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hammer Quote: As an example, AmigaOS 4.1 on classic Amiga hardware with Phase 5 PPC couldn't fully run WB-friendly 68K Deluxe Music 2. That’s strange it does start on AmigaOS4.1 with NallePuh, a real Amiga should be more compatible than computer running with chipset software emulator. However, there is crash that’s cause by some kind of memory corruption issue. But sadly, we do not have the source code and can’t investigate what actually happens. Without a huge amount of time wasted on decompiling and reverse engineering, that’s is not going to happen. Run it in EUAE if you must run it. We know there compatibility issues between AmigaOS4.1 and Kickstart 1.2. that also true for Kickstart 3.1/3.0 as well, also not 100% compatible with Kickstart 1.2, this way games are packed in WHDLoad, to run games with the kickstart they were designed for. Back in the day I remember having Relokick 1.3 on a floppy disk.

FYI, DMusic2 works fine on Emu68. With RTG, DMusic2's desktop notation functions are still useful.

I did have Relokick 1.3 i.e. CU Amiga Magazine Cover Disk 52's Relokick 1.3.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hypex

Quote:

Hypex wrote: @matthey Quote: A high end Amiga should be using a full 68040 with MMU at that time not that there was a high end Amiga during the 68040 and 68060 era due to the gimped low end Amiga chipset. I was referring to low end hardware for the masses like an intermediate upgrade for the CD32+ between a 68EC030 and 68040. That's fine for the masses. But what were developers using to code and test their products? A common problem was bad coding practices and hacking into OS structures rather than code cleanly and leave it alone.

Which is simply false: they were NOT bad coding practices. In fact, they were perfectly legit according to Commodore's guidelines!
Quote:

I wouldn't like that either as using a prefix for 68K encodings would be wrong. An issue may be in the encoding of MOVE, as once example with size. The front nibble is 00SS with size. But SS is only 1 to 3. A logical progression to use 0 as quad. But ORI also uses 0000. However, MOVEP also uses 0000. The coding differs later in the opcode.

That's why a redesign / reorganization of the opcodes for a 64-bit execution mode would be much better than recycling the 68k legacy and adding a horrible patch like a prefix.
Quote:

Now if the basic opcodes can fit a 64 bit op into 16 bits that can be built on. But, there are also 64 bit extensions to complicate it, such as DIVU/DIVS where the 64 bit wide data is split into register pairs. These would all need extending to wide registers. A possibility is 32 bit opcode which would impact code density. But the penalty wouldn't be as bad as RISC for wide data since all 64-bit size data words can be packed with a 32-bit sized opcode.

I don't see the problem: you can have both 16 and 32 bit opcodes. Like the current 68k design. Only much better organized.
Quote:

Hypex wrote: @cdimauro Quote: 68k ha 32-bit opcodes as well... With VLE it would yes. AFAIK the encoding is base 16 bit, that is 16 bit based so all codes are multiples of 16 bits, plus any data.

Yes, but not only data: even opcode information can be present on a subsequent 16-bit word. I mean: for 32-bit opcodes.
Quote:

Quote: 8 vector registers is too little. That's too bad as the core design has 8 each for address, data or floats. Though, given address and data combined would make 16 GPRs, perhaps encoding could offer 16 vectors.

It could be made in a backward-compatible way: see the previous comments exchanged with Matt.
Quote:

It's likely an SIMD extension would logically extend opcodes.

Sorry, I don't get it: could you please clarify it?
Quote:

Quote: There were some bits that were used for the SIMD (not Vector) unit. That's in F-line, of course. F-line, with it's friend A-line, popular for extensions. And being F for Floating point. Perhaps it started with F-it, we need more space.

Well, it has plenty of space (a precious 12-bit opcode space), but (very) badly used by Motorola...
Quote:

Quote: Who defines the standard(s)? Do you know that prefixes are being proposed for the PowerPC ISA? Whoever designed the 68K encoding scheme. It would use postfixes though really it's not exactly fixing it.

Prefixes and postfixes/suffixes are the same: crap!
Quote:

It's more like parameters or operameters. But also, prefix suits x86/x64 because it's little endian, so prefixing a byte is natural. 68K is big endian, which really only affects byte ordering, but VLE is opcode first followed by any operand extension.

I don't see the difference: you can use prefixes are well there, even with a big-endian architecture.


@Hammer

Quote:

Hammer wrote: @matthey Quote: The x86-64 ISA uses a pre-fix to access the upper 8 of 16 GP registers resulting in a decline of code density. The main purpose of x86-64 is the ability to access larger memory storage without PAE36's memory segmentation. If there is a low memory storage requirement, then stay with IA-32.

You forgot the extra 8 registers (GP, SIMD) that it introduced...
Quote:

When the 32-bit x86 extension came out, there were a lot of empty spaces available in the opcode space, therefore Intel chose a free byte that hadn’t been used in 16-bit mode to indicate 32-bit registers. Hence in 16-bit mode, if the CPU sees those bytes it knows that they’re 32-bit instructions and never mistreats them as 16-bit ones.

That's not true. Those prefixes were/are used to INVERT the specific feature.

Even in 16-bit mode, by default you can have 32-bit operands (!) and use the 0x66 prefix to switch the operands to 16-bit.

FYI: https://en.wikipedia.org/wiki/Segment_descriptor
D = Default operand size : If clear, this is a 16-bit code segment; if set, this is a 32-bit segment.
Quote:

Among the removed instructions, DEC and INC are not as useful as before in modern architecture. They’re all in 0x4X format, so they are used as REX prefixes for extra bits of the register encoding and selecting between 32 or 64-bit registers.

INC and DEC were and are still useful even in modern architectures. However their encodings had to be sacrified for the REX prefix (engineers lacked creativity about how to introduce a 64-bit execution mode in a much better way).
Quote:

Later to double the number of registers to 32 in AVX-512 and add some features like 3-operand instructions another encoding has to be invented that uses the VEX prefix.

No, EVEX was used for introducing AVX-512 and before that VEC was used for introducing AVX/-2.
Quote:

Hammer wrote: @NutsAboutAmiga Quote: NutsAboutAmiga wrote: @Hammer That’s strange it does start on AmigaOS4.1 with NallePuh, a real Amiga should be more compatible than computer running with chipset software emulator. However, there is crash that’s cause by some kind of memory corruption issue. But sadly, we do not have the source code and can’t investigate what actually happens. Without a huge amount of time wasted on decompiling and reverse engineering, that’s is not going to happen. Run it in EUAE if you must run it. We know there compatibility issues between AmigaOS4.1 and Kickstart 1.2. that also true for Kickstart 3.1/3.0 as well, also not 100% compatible with Kickstart 1.2, this way games are packed in WHDLoad, to run games with the kickstart they were designed for. Back in the day I remember having Relokick 1.3 on a floppy disk. FYI, DMusic2 works fine on Emu68. With RTG, DMusic2's desktop notation functions are still useful. I did have Relokick 1.3 i.e. CU Amiga Magazine Cover Disk 52's Relokick 1.3.

This comparison is a non-sense: OS4 only emulates the CPU and a bunch of things for the hardware, whereas Emu68 running on PiStorm has the original hardware behind...

@cdimauro

Quote:

Which is simply false: they were NOT bad coding practices. In fact, they were perfectly legit according to Commodore's guidelines!

Not with what I'm thinking of. I'll give you an example. Some coders like to read back what AllocVec returned and peek around inside, assuming it contains the exact length they gave it, stored before the memory. What's there is irrelevant and system private. It could be aligned so if they needed an exact size they need to manage it them self.

Another example. Gloom 3. For whatever reason this hacks into the CIA resource where the keyboard vector is for the keyboard.device and changes the code. There goes a so called friendly OS game. I certainly don't think Commodore advised to hack into OS resources like that!

Quote:

That's why a redesign / reorganization of the opcodes for a 64-bit execution mode would be much better than recycling the 68k legacy and adding a horrible patch like a prefix.

It looks like it would be. It would complicate decoding with another layer but with expansion such complexities need to be dealt with. What I then wonder is how the usual sizes of B/W/L would fit in? Of course a 64-bit mode would be designed to address that.

Quote:

I don't see the problem: you can have both 16 and 32 bit opcodes. Like the current 68k design. Only much better organized.

Not that it's a problem per se, but some opcodes may extend to 32-bit, where with smaller data a 16 opcode would have covered it.

Quote:

Yes, but not only data: even opcode information can be present on a subsequent 16-bit word. I mean: for 32-bit opcodes.

Yes, two words in that case, 2x 16-bits. Opcode, operand, is there a term for opcode parameter/flags/info?

Quote:

It could be made in a backward-compatible way: see the previous comments exchanged with Matt.

I see.

Quote:

Sorry, I don't get it: could you please clarify it?

I think what I meant here is that given SIMD needs to deal with larger datatypes, usually partitioned into smaller packets or as one length, plus all the operations then naturally the opcodes would be larger and be extended 32-bit opcodes.

Quote:

Well, it has plenty of space (a precious 12-bit opcode space), but (very) badly used by Motorola...

Unfortunately as it turned out.

Quote:

Prefixes and postfixes/suffixes are the same: crap!

Lol. There's a fine between a prefix and a postfix coded as an opcode parameter. A 68K 32-bit opcode would contain a 16 bit opcode then 16 bit postfix for want of a better expression

Quote:

I don't see the difference: you can use prefixes are well there, even with a big-endian architecture.

What I mean is, for prefixing a byte, it makes sense for x86 since opcodes are not restricted in width and can be as small as a byte. For a big endian with 16-bit opcode width, it needs a word for any prefix, so the prefix would need the same space as any opcode to become a modifier.

Quote:

INC and DEC were and are still useful even in modern architectures. However their encodings had to be sacrified for the REX prefix (engineers lacked creativity about how to introduce a 64-bit execution mode in a much better way).

I imagine they would have been pretty common and useful so was surprised when I read that.

Quote:

This comparison is a non-sense: OS4 only emulates the CPU and a bunch of things for the hardware, whereas Emu68 running on PiStorm has the original hardware behind...

It used to emulate more. On my XE left mouse was emulated. On my X1000 it doesn't work.

@Hammer

So I located DMusic and tried it myself. It loads up fine and the window on screen looks fine. But when I tried to play it crashed. It was a common null pointer. First it crashed in the OS4 audio.device. Then later in DMusic itself. Hard to know what's happening there. Without any way to live debug 68K binaries it can't be spotted directly. Some kind of device debugger would help though.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Which is simply false: they were NOT bad coding practices. In fact, they were perfectly legit according to Commodore's guidelines! Not with what I'm thinking of. I'll give you an example. Some coders like to read back what AllocVec returned and peek around inside, assuming it contains the exact length they gave it, stored before the memory. What's there is irrelevant and system private. It could be aligned so if they needed an exact size they need to manage it them self. Another example. Gloom 3. For whatever reason this hacks into the CIA resource where the keyboard vector is for the keyboard.device and changes the code. There goes a so called friendly OS game. I certainly don't think Commodore advised to hack into OS resources like that!

OK. THOSE are bad coding practices, for sure.
Quote:

Quote: That's why a redesign / reorganization of the opcodes for a 64-bit execution mode would be much better than recycling the 68k legacy and adding a horrible patch like a prefix. It looks like it would be. It would complicate decoding with another layer but with expansion such complexities need to be dealt with. What I then wonder is how the usual sizes of B/W/L would fit in? Of course a 64-bit mode would be designed to address that.

There are two ways:
- you can keep the existing instruction encodings. Then in this case all instructions which used Size = 11 should be moved to a new encoding. Which means: new 32 bit opcodes. There aren't so many 16-bit opcodes, unless you want to use line-A for moving there all instructions which were mapped on the MOVE.Q encoding (MOVE with Size = 11);
- you can define a completely new encoding scheme, based / inspired by the existing one.

For the latter is always the best option, because a new architecture is by definition binary incompatible with the previous one, so it's better to take full advantage of a new design.
Quote:

Quote: Yes, but not only data: even opcode information can be present on a subsequent 16-bit word. I mean: for 32-bit opcodes. Yes, two words in that case, 2x 16-bits. Opcode, operand, is there a term for opcode parameter/flags/info?

No: they are just fields in the opcode structure.
Quote:

Quote: Sorry, I don't get it: could you please clarify it? I think what I meant here is that given SIMD needs to deal with larger datatypes, usually partitioned into smaller packets or as one length, plus all the operations then naturally the opcodes would be larger and be extended 32-bit opcodes.

Yes, SIMD instructions tend to be large because they carry more information. USUALLY.

But a nice SIMD extension with a good compromise can be made for 68k, keeping 32-bit opcodes.
Quote:

Quote: Prefixes and postfixes/suffixes are the same: crap! Lol. There's a fine between a prefix and a postfix coded as an opcode parameter. A 68K 32-bit opcode would contain a 16 bit opcode then 16 bit postfix for want of a better expression

Please, no!
Quote:

Quote: I don't see the difference: you can use prefixes are well there, even with a big-endian architecture. What I mean is, for prefixing a byte, it makes sense for x86 since opcodes are not restricted in width and can be as small as a byte. For a big endian with 16-bit opcode width, it needs a word for any prefix, so the prefix would need the same space as any opcode to become a modifier.

Indeed. Which means that code density can be heavily (negatively) affected by this.
Quote:

Quote: INC and DEC were and are still useful even in modern architectures. However their encodings had to be sacrified for the REX prefix (engineers lacked creativity about how to introduce a 64-bit execution mode in a much better way). I imagine they would have been pretty common and useful so was surprised when I read that.

That's the general understanding and opinion.

AMD decided to remove those instructions to introduce its x64. Very very bad idea: another huge patch applied to a monster, which made the situation even worse.

It happens, when engineers lack creativity...
Quote:

Quote: This comparison is a non-sense: OS4 only emulates the CPU and a bunch of things for the hardware, whereas Emu68 running on PiStorm has the original hardware behind... It used to emulate more. On my XE left mouse was emulated. On my X1000 it doesn't work.

Hey, but this is really trivial stuff to emulate! This is the super simple and easy part to emulate from the CIAs.

How is it possible?!?
Quote:

Hypex wrote: @Hammer So I located DMusic and tried it myself. It loads up fine and the window on screen looks fine. But when I tried to play it crashed. It was a common null pointer. First it crashed in the OS4 audio.device. Then later in DMusic itself. Hard to know what's happening there. Without any way to live debug 68K binaries it can't be spotted directly. Some kind of device debugger would help though.

Hasn't Petunia (or TranceJIT. Or any other stuff like that) any possibility to fully trace the execution of an application?

I expect that something like that was made by his developer, otherwise it's a nightmare to figure out issues like those and fix the bugs in the JIT...

@cdimauro


Quote:

INC and DEC were and are still useful even in modern architectures. However their encodings had to be sacrified for the REX prefix (engineers lacked creativity about how to introduce a 64-bit execution mode in a much better way).

FYI, AMD64 was co-designed with Microsoft.

Intel's 64-bit migration POV is irrelevant to Microsoft-AMD. Intel has its chance with IA-64 Itanium.

Microsoft told InteI to accept AMD64 as the 64-bit extension for X86.

Repurposing INC and DEC for AMD64 didn't impact Microsoft's legacy software products.

"Designed For Windows" matters and it's a big elephant in the room.

When Microsoft stated NPU as a standard for incoming Windows 12, AMD and Intel followed MS's direction.

When Microsoft states USB 4.0 40 Gbps and rejects USB-IF's USB 4.0 20 Gbps as part of the "Design for Windows 11 "logo requirement, the PC industry follows.

USB-IF's USB 4.0 20 Gbps argument effectively renames USB 3.2 2x2's 20 Gbps and MS didn't accept this BS. USB-IF's USB 4.0 20 Gbps will be labeled as USB 3.2 by MS.

Last edited by Hammer on 10-Dec-2023 at 12:19 PM.
Last edited by Hammer on 10-Dec-2023 at 12:07 PM.
Last edited by Hammer on 10-Dec-2023 at 12:05 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: INC and DEC were and are still useful even in modern architectures. However their encodings had to be sacrified for the REX prefix (engineers lacked creativity about how to introduce a 64-bit execution mode in a much better way). FYI, AMD64 was co-designed with Microsoft.

There's the no source about it.

AMD collaborated with Microsoft for support x86-64, and that's (obviously) true. But that's totally different from designing the new architecture.
Quote:

Intel's 64-bit migration POV is irrelevant to Microsoft-AMD.

See above: only to AMD.

In fact, Microsoft supported Intel's Itanium before x86-64...
Quote:

Microsft told InteI to accept AMD64 as the 64-bit extension for X86.

That's a completely different story, and made sense.
Quote:

Repurposing INC and DEC for AMD64 didn't impact Microsoft's legacy software products.

This is non-sense: what are you talking about?!?
Quote:

"Designed For Windows" matters and it's a big elephant in the room.

Right, and? What's the problem here?!?

@cdimauro

Quote:

cdimauro wrote: There's the no source about it.

Microsoft actually worked with AMD in the early days to create the AMD64 processor.

https://news.microsoft.com/features/the-engineers-engineer-computer-industry-luminaries-salute-dave-cutlers-five-decade-long-quest-for-quality/

Cutler stopped managing the entire NT project in 1996, but continued to lead the kernel development until 2006. In March 2005, he completed one of his “most gratifying pieces of work” at Microsoft when, partnering with AMD, he helped develop the AMD64 architecture (64-bit extensions to the 32-bit x86 architecture) and led the effort to ship the first two x64 64-bit Windows systems (workstation and server).


Removing Bill Gates from MSFT's CEO position in year 2000 also removed Bill Gates's pro-Intel intervention for the original Xbox.

https://www.theregister.com/2021/10/14/xbox_sorry_amd/
One of the developers of the original Xbox apologized to AMD for Bill Gates's pro-Intel intervention in the Xbox project.


As we approach @Xbox 20th, I feel a need, once again, to apologize for the literal last second, @AMD engineers-who-helped-us-make-the-prototype-boxes-sitting-in-the-front-row-for-the-announcement switch to an Intel CPU. It was Andy calling Bill. Not me. @LisaSu I beg mercy.

— Seamus Blackley (@SeamusBlackley) October 12, 2021


Bill Gates's pro-Intel influence was removed around the early 2000s and Xbox 360 has IBM Power64-based PPE CPU.


Itanium (IA-64) has HP's big endian Unix interest.


Quote:

AMD collaborated with Microsoft for support x86-64, and that's (obviously) true. But that's totally different from designing the new architecture.

See above.

Quote:

In fact, Microsoft supported Intel's Itanium before x86-64...

IA-64 has support from HP and Intel and they both failed.

https://betawiki.net/wiki/Windows_XP_64-Bit_Edition
Windows XP 64-Bit Edition for Itanium Systems

Version 2002 wasn't feature-completed when compared to the Windows XP X86 version.

Only Service Pack 1 was released for this edition of Windows XP, despite Service Pack 2 for Windows XP x86 being released before the announcement to end support for the IA-64 editions.

A compatibility layer called WoW64 allowed the execution of applications compiled for x86 versions of Windows and this compatibility layer used an on-chip decoder integrated into the Itanium processor and was slow.


Version 2003
The second release of Windows XP 64-Bit Edition which calls itself Version 2003 was released on 28 March 2003. This version adds support for the Itanium 2 processors and is based on the Windows Server 2003 codebase.

Unlike x86 versions of Windows XP, it didn't have the Luna theme and was still missing several features compared to the x86 versions of Windows XP.

Since the decision to end support for this version of Windows was made during the development of Service Pack 1, only pre-release builds up to build 3790.1260 can be installed.

All later builds can only be installed on Windows Server 2003 and will fail with an error message when attempting to install them on Windows XP 64-Bit Edition, Version 2003. It is however possible to install both RTM versions of Service Pack 1 and Service Pack 2 for Windows Server 2003 with a workaround.

-----


Windows XP 64-Bit Edition for Itanium is garbage for gaming PCs.

Windows XP X64 is a feature complete with Windows XP x86.

AMD64's recycling of the existing prefixes doesn't impact MSFT's legacy software.

Last edited by Hammer on 10-Dec-2023 at 01:18 PM.
Last edited by Hammer on 10-Dec-2023 at 01:17 PM.
Last edited by Hammer on 10-Dec-2023 at 01:14 PM.
Last edited by Hammer on 10-Dec-2023 at 01:07 PM.
Last edited by Hammer on 10-Dec-2023 at 01:03 PM.
Last edited by Hammer on 10-Dec-2023 at 12:48 PM.
Last edited by Hammer on 10-Dec-2023 at 12:43 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro

Quote:

This is non-sense: what are you talking about?!?

You can't handle the truth.

Quote:

Right, and? What's the problem here?!?

Big elephant in the room.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro

No there are no built-in way step into the 680x0 code,
That be hard to do in forbid states as well, sense you can't operate a GUI, maybe you control over rs232, but that be messy.

You need to decompile the code. Add debug stuff to it and recompile it.
in any case you need to do that in any case, when find the bug, to create the binary patch.

Last edited by NutsAboutAmiga on 10-Dec-2023 at 01:34 PM.

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