Amiga - a 16bit or 32bit machine?

[ejstans]

Eh, okay, it maybe a bad example, (or not, as you point out the programmer part of it).
Still, offscreen and backface culling done by hardware should be faster.
AFAIK this also enabled the Dreamcast to be able to render cell shaded games like Jet Set Radio.

The technique of the Dreamcast (the PowerVR chip really) was not about backface culling or anything like that. The aim was to achieve a high fill rate by avoiding overdraw. It worked by processing tile by tile instead of polygon by polygon. The graphics core had a 16x16 pixels (if I recall correctly) tile buffer with a Z-buffer with very high bandwidth. The framebuffer was divided into an array of tiles, and instead of directly rendering a polygon, the graphics core stored the vertex information in a buffer. After the polygon data for a scene had been submitted, the graphics core would go through each tile and determine which polygons might be visible there. Then it would render all those polygons to the internal tile buffer. After all polygons for that tile had been rendered to the high bandwidth buffer, the contents was copied to the appropriate slot in the framebuffer tile array. This technique minimized memory bandwidth requirements by avoiding all overdraw (or overhead from updating the Z-buffer) at the cost of having to have a vertex buffer to collect polygon data. Of course techniques such as backface culling were also used to minimize the number of polygons to be rendered.

Oh, and to get back on topic, the 68000 only had a 16-bit ALU which means any 32-bit operation takes longer time to execute. Why not stick with the 16/32 moniker?

[ejstans]

The falcon used a 16-bit databus for the CPU. As I said, the 68020 (and 030) are perfectly happy running on narrow data buses. Only the number of cycles required to transfer 32-bit words is affected. You can run a 68020 on an 8-bit databus if you really want.

Hence the reason for preferring GPR width over concerns like buses and memory organisation.

My GPU has a 448-bit bus, I wouldn't call it a 448-bit machine

Gosh, what a silly thing to do, to needlessly starve a CPU on memory bandwidth! I doubt the 68030 was very happy with that arrangement!

Anyway, what possible use is it to dub a machine this-or-that many bits? By itself, such a number is completely useless. Remember the CD32. What a laff compared with Saturn or Playstation in the 32-bit console battle...

Hmmm, the Playstation, now that was a beautiful machine :cool:

[ejstans]

oh noooo... not this old hat rechewed once again.

the 68000 was designed as a full 32bit cpu, only cost restriction caused external busses to be restricted to 16 (or late 24) bits. Study the cpu design docs as I did in 1991 for my university project.

end of story - move on

Tom UK

Well, that's not exactly how I remember it. It clearly wasn't designed as a full-fledged 32-bit cpu since important internal structures are only 16-bit.

It was realized that 16-bits did not provide enough address space, and rather than choosing some page-mode or other kludge they went all 32-bit on the address space. Only the lower 24 bits were routed to external pins as a means to keep pin count down and 16 MiB ought to be enough for everybody!

In order to avoid the mess with different sized address and data registers, the data registers too became 32-bit wide. The external data bus was only 16-bits though, probably to keep pin count down, but also maybe because 16-bit ops were thought of as the primary mode of operation and the slower 32-bit ops were only icing on the cake sort of speak...

[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...

[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...