@ppcamiga1

Stop embarrassing yourself (actually do continue, it's funny). The thread asks "what is wrong with 68k". So, we're talking about things we (subjectively) think are bad with the 68K. Not the Amiga per se, but the CPU, it's instruction set, implementation, etc.

Notwithstanding the fact that getting a zero flag update on loading an address register would be free win, it's also a departure from the move behaviour in general. When you transfer data from any location to a data register, CC are updated. When you transfer data from any location to a memory address, CC are updated. Not updating at least the Z flag (I can see plenty of reasons to ignore the rest) for a move to an address register is not only annoying but inconsistent with move semantics for all other cases.

_________________
Doing stupid things for fun...

Karlos Quote:

Nobody is talking about what risc chips do, most of them don't have the concept of separate address registers anyway. The point is, the 68000 designers decided to update CC for move operations generally and it's useful. Setting the zero flag for address loads would've been useful and I strongly doubt would have added any significant complexity.

The condition codes are important for instruction scheduling. RISC architectures have been designed to make pipelining and instruction scheduling easier which is an advantage including for OoO dynamic instruction scheduling. RISC architectures generally increased instruction counts, increase code size, lose powerful CISC mem access instructions that are the equivalent of 2 or more RISC instructions and add load-to-use stalls of memory loads which often more than offsets the gains though. RISC architectures and designs tried to correct some of these disadvantages by adding more GP registers so there are fewer costly load/store mem accesses, improved code density over the dead classic like RISC ISAs and borrowed CISC like core designs that eliminated load-to-use stalls. I also talk about RISC designs because most new CPU core designs are load/store RISC hybrids with x86-64 one of the few CISC architectures still developed and it is a poor example despite remaining the performance architecture partially due to CISC performance advantages. CISC architectures should improve more than x86-64 did over x86. I believe adding address register destination CCR Z flag updating to 68k64 would be a step in the wrong direction and would make instruction scheduling more difficult. A separate CCR-A and CCR-D, or at least CCR-A Z and CCR-D Z, may be better but adding a test and branch (TBcc) instruction may be the best way to improve address register testing.

Karlos Quote:

I think people overestimating the complexity of checking all bits 0 when loading an address register and equally underestimating the value of knowing if it's null "for free" i.e. without additional test/compare/move via a data register first. I'm certain nobody would be complaining if it had set the Z flag since day 0, it would just be accepted as a sensible behaviour for dealing with addresses.

The complexity is not so much in testing and setting the CCR Z flag but in storing and tracking the CC flags.

https://www.righto.com/2023/02/silicon-reverse-engineering-intel-8086.html Quote:

Zero flag The zero flag is also straightforward. It indicates that the result byte or word is all zeros, for a byte or word operation respectively. An 8-input NOR gate at the top of the flags circuitry determines if the lower byte is all zeros, while an 8-input NOR gate at the bottom of the flags circuitry tests the upper byte. These NOR gates are spread out and span the width of the ALU, essentially a wire that is pulled low by any result bits that are high. The zero flag is set based on the low byte or the whole word, for a byte instruction or word instruction respectively. ... You might expect flags to be a simple part of a CPU, but the 8086's flags are surprisingly complex. About 1/3 of the ALU is devoted to flag computation and storage. Each flag is implemented with completely different circuitry. The 8086 is a CISC processor (Complex Instruction Set Computer), where the instruction set is designed to be powerful and to minimize the gap between machine language and high-level languages. This can be seen in the implementation of the flags, which are full of special cases to increase their utility with different instructions. In contrast, a RISC (Reduced Instruction Set Computer) simplifies the instruction set to make each instruction faster. This philosophy also affects the flags: for example, the ARM-1 processor (1985) has four arithmetic flags compared to the 8086's six flags. The behavior of the ARM flags is simpler, and the ARM doesn't deal with byte versus word operations. It also doesn't have instructions like decimal adjust that have complex flag behavior. This simplicity is reflected in the simpler and more regular circuitry of the ARM-1 flags, which I reverse-engineered here.

Pipelined, speculative execution and OoO CPU designs increase the flag storing and tracking complexity. Avoiding unnecessary CC flag changes is an advantage but accomplishing it has disadvantages as well.

@matthey

Just a reminder. All CC flags are updated for all other normal move cases (not movem, move to ccr, etc) regardless of source or destination effective address. It was probably more complicated to explicitly not do it for address registers.

_________________
Doing stupid things for fun...

@ppcamiga1

Quote:

ppcamiga1 wrote: biggest annoing thing in 68k is lack of nice fast usable graphics at rational price something as good as fast as ocs in ex 1992 in 2008 natami/apollo/vampire start this whole thing about upgrading chipset but 17 years later 68k camp still has nothing

In the OP you said,
Quote:

So what is wrong with 68k? in amiga world? it is still not as fast as comfortable as cheap pc from windows 95 era. Still nothing native, with MMU, FPU, 2D and 3D Pentium 100 performance for resonable price. still after almost 30 years amiga 68k not reach level of pc from windows 95 era. what 68k amiga followers should do try to reach 1995 standards instead of trolling.

What's wrong with this opinion?

1. It's PC envy. Who cares how fast or 'comfortable' some other platform is if you are happy with your current one?

2. It's debatable that a 1995 PC was as great as you say.

A PC with Pentium 100 in 1995 wasn't cheap. DOS wasn't 'comfortable', and Windows 95 (released in late August 1995) had a lot of compatibility issues.

The 'cheap' S3 ViRGE, ATI Rage, and Matrox Mystique 3D cards didn't arrive until 1996, and they were poor performers. The first 3D graphics chip that was any good was the 3DFX Voodoo, which was first used in the Diamond Monster 3D 3dfx Voodoo1 released in November 1996 (I got one to run Tomb Raider). This was a separate card that only did 3D, no 'native' screen modes. It didn't use Direct 3D or Open GL, so games had to be written specifically for its proprietary Glide API.

3. By 1995 the Amiga was a retro computer.

Commodore was gone and the Amiga wasn't being manufactured any more, so we didn't expect to see new more powerful models come out. Instead we would add 3rd party accelerator cards, graphics cards, bus interfaces etc. - just like we always did. 68030 accelerator cards were popular and by 1995 were quite cheap (much cheaper than buying a new PC). By the late 90's 040 and 060 were available at 'reasonable' prices too.

Back in 1995 these things were expensive by today's standards, but not anymore. Today you only have to spend the equivalent of US$100 in 1995 money for a PiStorm with RPi3a, giving your Amiga equivalent power to a 2000+ era PC. And unlike a PPC 'Amiga' it's still fully 68k, so you can continue to enjoy the platform you are comfortable with.

However many of us are quite happy with performance similar to what our Amigas had back in 1995. I feel very comfortable using my A1200 with 50MHz 030. The only upgrade it's had since the 90's is increasing RAM from 16MB to 32MB. I'm still using the same CNet PCMCIA network card that I developed a driver for back then (only now using Roadshow instead of AmiTCP because it's faster, and of course the latest IBrowse and AmiSSL). I haven't upgraded the ROM either, as 3.0 is good enough and I am comfortable with it.

Similarly with the display - I run Workbench in 640x256 with 8 colors to my TV in composite, which works much better on my 32 inch LCD TV than it did on the enormous 29 inch CRT TV I used to have. It even fixes flicker in interlace modes, making web browsing very practicable (and sufficiently colorful even in only 8 colors due to IBrowse's intelligent dithering and the smoothing effect of composite).

Talking about speed, I can boot my A1200 from cold in 15 seconds, run Roadshow and IBrowse and be downloading the latest Aminet files, searching with Google or reading posts on this site before my Linux PC has even booted to the desktop. My Windows XP PC is even slower, taking another minute to start the network - while the A1200 takes 2 seconds. Firefox on my Linux PC takes about 20 seconds to start up, and 2 minutes to shut down (during which time it hogs the CPU, preventing me from doing other stuff - then it crashes). This isn't comfortable, it's incredibly annoying, but there's nothing I can do about it because debugging 'modern' software is practically impossible for mere mortals.

The 50MHz 030 in my A1200 runs Doom fast enough to have fun, and AGA graphics provides identical visuals to a PC. But there are lots of great 68k Amiga games that are more fun and don't even need an 030 - and more are coming out. The only game I used to play on the PC was Tomb Raider - until a mouse piddled on the graphics card and killed the AGP slot. The onboard graphics chip won't work with it (driver issue I presume) so I haven't played any games on it since.

My Amigas are now my 'fun' machines. I tried getting into retro PCs but it just just brought back memories of endless frustration. I bought a 386SX motherboard which looked pristine but only ran for a few minutes before dying. The 486 PC I bought had a battery leak that killed the motherboard and was unrepairable. Then I bought a more modern PC with Windows 7 and it was dog slow - not an enjoyable experience. Someone gave me a laptop with Windows 10 on it and oh boy, what a POS that OS is. 4 gigabytes of RAM and it still struggles.

As for programming a modern PC in asm (my favorite computer activity) forget it. x86 code is yuk and the OS prevents you from doing fun stuff without going through hoops. PC GUIs are no fun either. No screen dragging so everything has to run on the desktop, ugh. No thanks, I'll stick to the platform I'm comfortable with.

Last edited by bhabbott on 11-Jan-2025 at 03:07 AM.

@Lou

Quote:

A500/2000 should have been 020 machines.

Please remember the problems with the price of an Amiga, I would have been glad if an A2000 had a 16MHz 68000, there where very cheap CPU cards for the Atari that had a tiny cache and and a 16MHz CPU, this should have been built into the mainboard, giving the expensive A2000 some improvements over the A500.

The A500 has always been the low cost model, maybe that should have sold it with an A1000 compatible Zorro-I slot.

Last edited by OneTimer1 on 11-Jan-2025 at 01:27 AM.

@OneTimer1

Quote:

OneTimer1 wrote: I regretted the differences of address and data registers, understanding and remembering the differences, made assembler programming harder.

Then you must think other CPUs are horrible. x86 for example doesn't set flags for any Move, Load or Store operation. 8080 and Z80 don't set flags on inc or dec of any register except A (to test a 16 bit register pair for zero you do eg. LD A,B : OR C).

Most of the time 68k address registers can be assumed to contain a valid address, so the z flag is redundant. OTOH, being able to modify an address register before testing flags from an earlier operation can be useful. It may save several instructions and make the code faster.

You just have to remember the simple rule - if the MOVE destination is an address register then flags aren't affected, if it's a data register or memory location then they are (except for MOVEM, and of course move from sr/ccr). This makes sense because address registers are assumed to be pointers, which should never be invalid!

Bear in mind too that the instructions MOVE, ADD and SUB are actually MOVEA, ADDA and SUBA when the destination is an address register. Most assemblers accept both for convenience, but you may want to use the 'correct' one to make it more obvious that an address register is involved (I do).

Quote:

But maybe it made it easier for CPU designers, AFAIK they could do address calculations parallel (or was it pipelined ?) to data register handling. The 8086 had to use the ALU for address calculations.

Correct. Address registers are manipulated directly without going the the ALU. They have a simple adder circuit that doesn't include testing for zero etc., which saves a bunch of transistors and avoids the complication of how to combine status flags.

Last edited by bhabbott on 11-Jan-2025 at 02:16 AM.

@Karlos

Quote:

Karlos wrote: @matthey Just a reminder. All CC flags are updated for all other normal move cases (not movem, move to ccr, etc)...

Move to ccr is a tricky one. The data moved into ccr sets the flags, so of course you don't want to 'update' them afterwards as that would defeat the purpose of the instruction! Similarly move from ccr and Scc don't affect the flags.

@OneTimer1

Quote:

OneTimer1 wrote: @Lou Quote: A500/2000 should have been 020 machines. Please remember the problems with the price of an Amiga, I would have been glad if an A2000 had a 16MHz 68000, there where very cheap CPU cards for the Atari that had a tiny cache and and a 16MHz CPU, this should have been built into the mainboard, giving the expensive A2000 some improvements over the A500.

A tiny cache wouldn't be much use unless you had FastRAM (unlike the ST, ChipRAM may be modified by the Blitter, so caching it is dangerous). The A2000 has a CPU slot for adding accelerator cards. They are expected to have onboard RAM running at the same speed (and bus width) of the faster CPU.

Quote:

The A500 has always been the low cost model, maybe that should have sold it with an A1000 compatible Zorro-I slot.

It is. At least 4 RAM boards were produced that could plug into both the A1000 and A500 (some had a different case for each). I plugged an A590 into my A1000 and it worked! Only problem is it was backwards.

@Karlos

Quote:

Karlos wrote: @ppcamiga1 Stop embarrassing yourself (actually do continue, it's funny). The thread asks "what is wrong with 68k". So, we're talking about things we (subjectively) think are bad with the 68K. Not the Amiga per se, but the CPU, it's instruction set, implementation, etc.

"What we've got here is failure to communicate"

When ppcamiga1 said '68k' he meant 68k Amigas as apposed to ppc 'Amigas'. So generic discussions about 68k CPUs vs others are actually off-topic.

OneTimer1 Quote:

I know, the 68k used a different bus cycle for this command, incompatible to the Amiga specific way organizing the DMA slots, TAS was meant to be 'atomic'. This is one of the few things where I would say: F__k compatibility, I'm curious what you are doing in Emu68k or what the Apollo team does?

Some lines in 68k CPUs did not make it out to CPU pins but this is solvable with a 68k+chipset SoC.

Gunnar von Boehn Quote:

a) Problem TAS/CAS/CAS2 The 68k provides hardware instruction for SMP syncronisation. Those SMP instruction did use read-and-modify busy cycles which could collide with the old AMIGA chipmem bus cycles. This problem is fixed! Apollo in combination with SAGA has solved this collisions. These instructions can now be used as expected!

Emulation need only support atomic instructions in fast memory like classic Amigas as they are for EOL compatibility and not a NG solution.

OneTimer1 Quote:

Alignment error is another one, it could have been fixed over the exception handler, but I never heard it was done. Later versions of the 68k (MC68SEC000, 68020 or higher) doesn't have this problem AFAIK.

Fixed assumes the 68000 not supporting an odd mem access alignment was broken. Most early RISC CPUs did not support misalignment either.

OneTimer1 Quote:

Just imagine a Unix like OS, where an illegal command could freeze a productive computer, things that where acceptable on an A500 would cause a major security issue today.

"Illegal" instructions are easy to freeze a computer. Using a Supervisor instruction in user mode works. Linux for the 68k Amiga was one of the earliest ports and the first port for the 68k. The port was possible by avoiding TAS, CAS and CAS2 in chip memory and maybe altogether.

OneTimer1 Quote:

Oh the 'move from SR' on 68SEC000 causes an exception when used in user mode unlike the original 68000, they have fixed this 'error' but caused a compatibility issue.

I would have thought a flag could have been placed in a Supervisor only configuration register that selects whether the MOVE from SR traps.

OneTimer1 Quote:

I regretted the differences of address and data registers, understanding and remembering the differences, made assembler programming harder. But maybe it made it easier for CPU designers, AFAIK they could do address calculations parallel (or was it pipelined ?) to data register handling. The 8086 had to use the ALU for address calculations.

The 68k address/data register split allows better code density with 16 GP registers. The registers are not fully orthogonal but are often considered so due to the limitations being well chosen. The 68k with 16 GP registers has better code density and much reduced memory traffic than x86 with only 8 GP registers. The 68k assembly rules are simple and consistent exhibited by the 68k being one of the easiest to program CPUs in assembly ever. Many 68k games were written in 68k assembly even though the 68k was known for being one of the easiest compiler targets too.

I believe you and bhabbott are correct about the design for parallel processing using different data and address registers.

code unit: instruction fetch, decode, OAG/EAcalc (address registers and PC)
data unit: operand/data fetch, ALU and CC flags (data registers and CCR)

Something like this could have allowed some parallelism even without pipelining as long as all the resources were available in the same unit. Not only does the register split make more sense with such parallelism but this also explains the lack of An register sources from many instructions even though most of the encodings are open and CC flags would not be affected. Sourcing resources from the other unit would reduce potential parallelism. With pipelining, 32-bit ALUs for a 32-bit ISA and large enough transistor budgets, the work could be reduced into small enough stages that a different strategy was used. The register file became monolithic and an instruction fetch pipeline and execution pipelines were used instead.

IFP: instruction address generation, instruction fetch, early decode, instruction buffer (PC)
OEPs: decode & select/issue, OAG/EAcalc, operand/data fetch, execute (address, data & CCR registers)
FPU: execute, (FPU & FPCR registers)

There is some resemblance of the original idea with changes made for better pipelining. The original register split is no longer necessary and I doubt any modern 68k CPU core design would ever require or make use of it again.

bhabbott Quote:

Then you must think other CPUs are horrible. x86 for example doesn't set flags for any Move, Load or Store operation. 8080 and Z80 don't set flags on inc or dec of any register except A (to test a 16 bit register pair for zero you do eg. LD A,B : OR C).

The following are a couple of other 808x/x86(-64) CC inconsistencies.

https://www.righto.com/2023/02/silicon-reverse-engineering-intel-8086.html Quote:

3. Unlike other arithmetic and logic instructions, the NOT instruction does not change any of the flags. The designer of the 8086 states that this was an oversight. (See page 98 in "The 8086/8088 Primer".) Looking at the microcode shows that the microcode F bit was omitted in the implementation of NOT. I think that this "goof" also prevented the NOT and NEG microcode from being merged, wasting four micro-instructions. ... 8. The parity flag only examines the low byte of the result, even for a 16-bit operation, making it unusual compared to the other flags. The motivation is probably that the parity flag was only supported for backward compatibility and not considered particularly useful. Even in modern 64-bit Intel processors, the parity flag only examines the least-significant byte.

Some people use a x86-64 CPU that is far less consistent about CC flags than the 68k but complain about inconsistent use of 68k CC flags.

bhabbott Quote:

Most of the time 68k address registers can be assumed to contain a valid address, so the z flag is redundant. OTOH, being able to modify an address register before testing flags from an earlier operation can be useful. It may save several instructions and make the code faster. You just have to remember the simple rule - if the MOVE destination is an address register then flags aren't affected, if it's a data register or memory location then they are (except for MOVEM, and of course move from sr/ccr). This makes sense because address registers are assumed to be pointers, which should never be invalid! Bear in mind too that the instructions MOVE, ADD and SUB are actually MOVEA, ADDA and SUBA when the destination is an address register. Most assemblers accept both for convenience, but you may want to use the 'correct' one to make it more obvious that an address register is involved (I do).

A pointer containing zero is valid and it would still be more useful to update the CC for zero on an address register write than preserve the CC flags. However, these are not the only considerations as I will continue below.

bhabbott Quote:

Correct. Address registers are manipulated directly without going the the ALU. They have a simple adder circuit that doesn't include testing for zero etc., which saves a bunch of transistors and avoids the complication of how to combine status flags.

There is a small logic simplification without the CC updates and easier instruction scheduling gives two advantages for not updating the CC on address register writes. However, zero and sign flag logic is simple while carry, overflow and parity (for 808x/x86/x86-64) flag logic is complicated. Setting a zero flag should be easy with later 68k designs using a monolithic register file and using the same ALUs for both register types. A separate zero flag for address register writes that is unaffected by data register writes and vice versa would preserve 68k compatibility but require a new instruction like BccA, where TBcc is likely preferable.

Last edited by matthey on 11-Jan-2025 at 04:20 AM.

@bhabbott

Quote:

bhabbott wrote: When ppcamiga1 said '68k' he meant 68k Amigas as apposed to ppc 'Amigas'. So generic discussions about 68k CPUs vs others are actually off-topic.

For this to be true, the rest of us would have to take ppcamiga1's posts seriously.

If we consider the art of conversation, irrespective of what the initial topic may have been, a conversation takes on a life of its own by those conversing. Thus when the majority of posts in a this thread are focused on the m68k CPU architecture itself, by >90% of the quorum, then the random ppcamiga1 post about 68k camp vs. PPC camp are the posts which are actually off the ongoing topic.

_________________
All the way, with 68k

@bhabbott

I pointed out move ccr, movem etc as exceptions to the "normal" qualifier. Obviously those shouldn't mess with cc (other than the explicit behaviour of move to ccr of course).

As for a failure to communicate, no. I know full well what the subject was supposed to be about, but hasn't it been done to death? How many times has the drivel about chunky pixels and mid 90s PC lust been said?

I saw an opportunity for an *interesting* tangent: what are the things people think are wrong with the 68K cpu?

I'll admit, I've been caught out a few times by idiosyncratic behaviours like moving a pointer into an address register and forgetting that it doesn't modify flags. And looking at a significant corpus of 68K code over the years, I'm not the only one. The highly orthogonal nature of the CPU and it's general flexibility steers you towards such exception cases. Helped along by relaxed assemblers that accept move as an alias for move and movea. Having to remember such exception cases to what is otherwise a very logical and well thought out instruction set.

Last edited by Karlos on 11-Jan-2025 at 09:47 AM.
Last edited by Karlos on 11-Jan-2025 at 09:02 AM.

_________________
Doing stupid things for fun...

Now that clarification is made, the other problems I have with the 68000 as an implementation of the 68000 architecture were pretty much addressed (pun half intended) with the 68010. Most importantly the ability to recover from various otherwise dead-end error cases, incomplete separation of supervisor and user mode due to the ability to mess with the status register and finally the ability to relocate the vector base. This is why I consider the 68000 itself as being akin to a beta release. The 68010 was the "proper" MVP.

_________________
Doing stupid things for fun...

Something that would have been nice to have is byteswapping. The swap instruction could have been better defined. Swapping two 16 bit halves of a register is useful sometimes, especially when doing things like division, to get the remainder, but I think that the ability to perform a full byteswap efficiently was an embuggerance.

My preferred implementation of that wouldn't actually be to extend the swap instruction per se (though that would be an MVP) but to have a move variant since that's actually a lot more useful for real world use cases like data conversion.

_________________
Doing stupid things for fun...

Having spent a long time with both, I can summarise the difference between 68K and PPC from a development perspective.

68K is a generally a joy to program directly but occasionally frustrating.
PPC is frustrating to program directly but with some occasional charm.

On the whole, PPC is better for development in higher level languages. Of course that's also it's biggest problem. As soon as you start writing software entirely in higher level languages, there are many better hardware targets to choose from, especially since it's demise in desktop computing.

On the very edge is the 68060. It can be frustrating to program directly compared to earlier models in order to extract the best performance from it and code tuned for it can be significantly worse on earlier CPUs. On the flip side it begins to perform a lot better than earlier models with compiled code.

_________________
Doing stupid things for fun...

@Karlos

Having spent a long time with both, I can summarise the difference between 68K and PPC from a development perspective.

68K lack nice fast easy to use graphics at rational price.
thats why making software for 68k is always frustrating.

PPC has always nice fast easy to use graphics.
thats why it is pleasure to made software for ppc.

Last edited by ppcamiga1 on 11-Jan-2025 at 01:40 PM.

@ppcamiga1

Name one single thing you have developed for either processor.

Statements like "ppc has nice fast graphics". Neither CPU has graphics. They have instructions. Some of those instructions are useful for graphical operations. The first desktop PPC that had instructions particularly useful for graphics operations was the G4, thanks to the introduction of SIMD, including things like saturated arithmetic. None of which were better suited for graphics than the fixed function pipeline of consumer graphics chips available by then.

But you know, keep up the bullshit.

Last edited by Karlos on 11-Jan-2025 at 01:50 PM.
Last edited by Karlos on 11-Jan-2025 at 01:49 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

PPC is frustrating to program directly but with some occasional charm.

I don’t really think so, there are that many instructions you need to learn to write assembler, some branches jumps, move’s and so on..

the general purpose registers, is good idea, no need to dedicate it to a address or data, just use have for what you need it for. On 680x0 you run out of register so often, and need to push to stack, so often.

acronyms can get boring, syntax bases assembler is easier to use, but if assembler was so great, you probably do that, create a language that has nice syntax that produces machine code, with correct opcodes.

What pains me the most is embedded chips, lack of instruction, the pit falls, you end up in when some instruction is not included, I think the worst part of it, is that end up think should use this instruction or not, is worth to write some code, is not going to work on a different cpu model of PowerPC.

Because have so many different PowerPC isa’s, we have to built the same things 3 times now. One for SPE, one FPU, and one for AltiVec, and perhaps one for amcc460 (ISEL), there special optimalization that done for QorIQ P5020, prefetch instructions etc.

You have the same for 680x0 as well, you need one that has support for FPU, one that does not support for FPU, and one has support for 68060 cache stuff. some optimize for 68000 that only has 16bit address bus.

Last edited by NutsAboutAmiga on 11-Jan-2025 at 09:12 PM.
Last edited by NutsAboutAmiga on 11-Jan-2025 at 02:59 PM.
Last edited by NutsAboutAmiga on 11-Jan-2025 at 02:55 PM.
Last edited by NutsAboutAmiga on 11-Jan-2025 at 02:54 PM.

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

@NutsAboutAmiga

Quote:

there are that many instructions you need to learn to write assemble

Well, except for the fact that every variation of the instruction seems to have it's own mnemonic form. The mnemonics themselves were/are awful and unmemorable. Backwards bit numbering. Special r0 behaviours. Branch link register for calls. It's just not friendly or appealing. That's fine because IBM didn't want you touching it anyway, you were meant to use C.

There are some good bits. I like having a choice which instructions should update flags as it gives me a bit more flexibility when arranging them for better execution. Masks on shifts are also quite neat.

Assembler on PPC. Yes, you can do it, but let's not pretend it's enjoyable - at least to people that have used it.

Last edited by Karlos on 11-Jan-2025 at 04:21 PM.

_________________
Doing stupid things for fun...

Ironically, you probably could design your own meta assembly language syntax for PPC that's significantly less awful. Choose sensible mnemonics. Add a size indicator on any operation that is sized (e.g as a distinctly visible thing similar to 68K and not a letter in the middle of some cryptic mnemonic). Add the mathematically coherent definition of bit numbering as their respective powers of two. Provide a simplified call/return.

Of course the only problem is, no matter how nice it is, nobody would use it.

Last edited by Karlos on 11-Jan-2025 at 04:25 PM.

_________________
Doing stupid things for fun...