Amiga - a 16bit or 32bit machine?

[Karlos]

From Wiki:

It is 16/32-bit. In other words both. A hybrid more or less. The PPC is pure 32-bit.
The x86 is also a hybrid, so hybrids seem to be the norm.

It's only a hybrid if you regard the physical bus into the outside world as important in the definition. That can vary even on the same processor. As I said previously, you can run a full 68020 on an 8-bit databus if you need to interface only with 8-bit peripherals.

The GPR definition is the best definition, since it overlooks all these considerations and focuses on the capability of the machine. If it has 32-bit general purpose registers that support the regular gamut of operations for 32-bit datatypes, then the machine is best described as 32-bit. The 68000 still falls into this category, even though it was slower at all 32-bit operations (using a 16-bit ALU and internal bus).

[stefcep2]

Whilst the ALU is 16 bits, I think there was a lot more to making a 32-bit register/instruction set model than "icing". Making the internal register model 32-bits wide was a mark of serious forward planning. Compare the 68000 to the 8086 design. After all, they'd gone for a separate data and address register model, they could easily have made d0-d7 16-bits wide and a0-a7 24-bits. It would have been cheaper and quicker to market.

  Ok so what made the TI99/4A the first 16 bit micro?

[Karlos]

Ok so what made the TI99/4A the first 16 bit micro?

Dunno. You'll have to ask whoever said it was

[stefcep2]

Dunno. You'll have to ask whoever said it was

thats what i was told when i bought one, over the 8-bit C64.  I think it was the CPU that was 16 bit

[ejstans]

Whilst the ALU is 16 bits, I think there was a lot more to making a 32-bit register/instruction set model than "icing". Making the internal register model 32-bits wide was a mark of serious forward planning. Compare the 68000 to the 8086 design. After all, they'd gone for a separate data and address register model, they could easily have made d0-d7 16-bits wide and a0-a7 24-bits. It would have been cheaper and quicker to market.

Yes, of course it was forward-planning, didn't mean to imply it wasn't. Just saying it wasn't exactly fully designed as 32-bit either. If it were, the ALU would have been able to handle 32-bits natively, as the later models did, without resorting to microcode hacks. No doubt the designers intended it to be forward-compatible with 32-bit software, which was a good thought indeed, but the processor was "optimized" (if you will) for 16-bit operations, and 32-bit operations induced cycle penalties in the best case, or wasn't even supported at all in the worst cast (multiply). The nomenclature of the operand sizes supports this idea too as a "word" is 16-bit and a "long-word" is 32-bit. The 16/32-bit name seems fitting enough to me...

[Karlos]

If it were, the ALU would have been able to handle 32-bits natively, as the later models did, without resorting to microcode hacks. No doubt the designers intended it to be forward-compatible with 32-bit software, which was a good thought indeed, but the processor was "optimized" (if you will) for 16-bit operations, and 32-bit operations induced cycle penalties in the best case, or wasn't even supported at all in the worst cast (multiply).

The important fact is that is that the 68000 presents a 32-bit programming model to the developer. How it is stitched together internally is never important given that it changes from generation to generation.

Regarding unsupported 32-bit operations 32-bit integer multiplication (with 64-bit product) isn't supported on the 68060 either

[Hammer]

Yes, of course it was forward-planning, didn't mean to imply it wasn't. Just saying it wasn't exactly fully designed as 32-bit either. If it were, the ALU would have been able to handle 32-bits natively, as the later models did, without resorting to microcode hacks. No doubt the designers intended it to be forward-compatible with 32-bit software, which was a good thought indeed, but the processor was "optimized" (if you will) for 16-bit operations, and 32-bit operations induced cycle penalties in the best case, or wasn't even supported at all in the worst cast (multiply). The nomenclature of the operand sizes supports this idea too as a "word" is 16-bit and a "long-word" is 32-bit. The 16/32-bit name seems fitting enough to me...

Pentium IV(Northwood)'s ALUs are 16bits wide and they are double clocked.

[Argo]

I'd say 32bit and always has been.

[ejstans]

The important fact is that is that the 68000 presents a 32-bit programming model to the developer. How it is stitched together internally is never important given that it changes from generation to generation.
 
Regarding unsupported 32-bit operations 32-bit integer multiplication (with 64-bit product) isn't supported on the 68060 either

Well, implementation details are unimportant if efficiency is ignored. You're right that the programmer is presented with a (close to) 32-bit environment. But if that's the only criteria for 32-bit architecture, Motorola could have saved pennies and shipped a processor with 8-bit data registers and a macro assembler to implement 32-bit arithmetics! :lol:
 
Sucks that that 68060 doesn't support 64-bit results in hardware, but of course, unlike the 68000, it does support 32-bit muls with 32-bit results at least. But nevermind, the SPARC V7 didn't even include an integer multiply instruction and it's still as much of a 32-bit architecture as anything
 
Anyway, call the 68000 processor 32-bit if you will, I don't really mind

[ejstans]

Pentium IV(Northwood)'s ALUs are 16bits wide and they are double clocked.

And because they are clocked twice as fast they can still perform 32-bit operations in one clock cycle...

[shoggoth]

http://en.wikipedia.org/wiki/Atari_Falcon

A 16-bit address bus would be pretty poor show. That would be in the same league as the ZXSpectrum and C64

Still, in practice it had higher bandwidth to ST-RAM (the equivalent of chipram) than the 1200. So bus width isn't all, at least not when caches are involved.

[Karlos]

And because they are clocked twice as fast they can still perform 32-bit operations in one clock cycle...

Actually it takes 3 cycles according to the info I read. In the first "fast" cycle, the lower 16-bits are added and ready for forwarding. Then the next 16-bits are added, then finally the condition codes set in a third cycle.

It's pretty stupid really, they could have had a 32-bit ALU and ran it at the same speed, which would have performed better.

Interestingly, a lot of arithmetic operations generated by the compiler use the effective address calculation hardware to evaluate operations, bypassing the ALU all together

[Zac67]

IMHO the P4 was pretty much a monstrosity right from the start, built entirely for high clock rates on paper - performance came second.

[bloodline]

IMHO the P4 was pretty much a monstrosity right from the start, built entirely for high clock rates on paper - performance came second.

Yeah, I second that!

The Pentium4 was the most atrocious architecture ever... I was an Athlon guy at that time.

The P4 was nothing more than an exercise in marketing... "Hey let's pump this CPU to 3Hgz!!!"... no regard for actual real world performance... That CPU killed the Pentium brand, the intel "Core" architecture was a breath of fresh air... and rather AMD like