Amiga - a 16bit or 32bit machine?

[Karlos]

One commonly used definition of width as understood by compilers is the width of a general purpose register. In that regard, the amiga is and always was a 32-bit machine.

[Karlos]

I imagine most 3D engines that run on the PS2 do backface culling, at the very least. There are many, many methods to throw away non-visible polygons, and leaving it until the hardware is about to render them is not a good idea. Really, you want to throw away non-visible polygons as early as possible.

This is actually a golden rule on every graphics pipeline I've looked at: The fastest elements are the ones you don't draw, so always eliminate stuff as early as possible.

Back face culling is a standard technique and one that's comparatively cheap to test for, even in software.

[Karlos]

Still, offscreen and backface culling done by hardware should be faster.

Not necessarily, it very much depends on how the graphics pipeline is implemented. If you have a complete hardware transform and lighting system then the chances are hardware culling may be faster since it is logically part of the transformation process.

However, if you have only a hardware rasterizer, which was true of most early generation 3D accelerators, then you've expended cycles to transform polygons and calculate their lighting, only to have the hardware discard them when their screen space orientation ends up being back facing.

Even something simple like hardware clipping can be slower when there are interpolants such as polygon colour to consider. For example, the chip might have to spend quite a while calculating the ramp value of a pixel that is going to be rejected. Clipping the polygon in software first before passing it to the rasterizer would result in a speed up then. This isn't theoretical either, the Permedia 2 was a prime example of a chip that you got the best performance when you eliminated backfacing polygons and clipped large shaded ones before passing the vertex data to the chip.

[Karlos]

Reminds me of the Ti-994's & TG-16 systems.

But I've always considered an Amiga running 16-bit ram to be a 16-bit computer.
Amiga's with 32-bit ram and NO 16-bit ram is a 32-bit computer. Mixture of both types
could just as well be considered 24-bit.  LOL!  And speed wise, you all know what I am
talking about.

Think of it this way. The 68020 is how many bits wide? You'd say 32, more than likely.

However, you can run a 68020 on a 32, 16 or even 8-bit data bus just fine. Buses do not define the machine, merely it's interconnectivity.

The reason the general purpose register width is taken as a metric is that it cuts through the hardware implementation of a system completely. The old 8-bit microprocessors may have had 16-bit address buses but they are considered to be 8-bit and not 16-bit simply because for most of them, you can't treat the 16-bit register pairs as single entities. Ok, there are usually a few basic arithmetic operations that can be performed on them, but it's normally only a subset of what can be performed on their respective 8-bit halves.

The 68000 still has 32-bit wide general purpose registers (including the address registers). Regardless of the ALU width and external buses, general purpose operations can be performed on all 32-bits of a 68000 register. It is therefore best considered a 32-bit processor.

[Karlos]

Actually the first ever 32bit console is the FM Towns Marty, released in February 1993.

And the X68000 is way more powerfull than the CD32 in terms of sprite/scrolling handling... 128 hardware 16x16 sprites.

Sprites, or blitter objects?

[Karlos]

Thanks for the explanation I couldn't find such detailed info on the net.

Yea, back in the day, the 68000 was considered a 16 bit proc. My Sega Megadrive is also labelled "16 bit".

So, was the 68030 powered Atari Falcon 16 bit then?

[Karlos]

Eh? The 68030 is, (as well as the 68020) clearly a 32bit processor, no?

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

[Karlos]

I can't find anything about it using a 16 bit databus, are you sure it's not about an address bus? They cut that down often back then, because memory was expensive and nobody would buy more memory than a reduced processor could handle.

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

Thankfully, the days of using bits and megaherzes are over . Still, and as always, it's up to the developer to make a system run or crawl. Considering that, there's still a lot to conquer.

You'd be surprised how easy the GPU is to program and how difficult it is to program well

[Karlos]

I don't understand that. For as far as I have read, the address bus doesn't affect the speed of the processor, yet the data bus does.

And therefore, yes, the Falcon does seem to be 16 bit. I guess it was it's main bottleneck, because IIRC the Falcon was considered to be slow.

I'd love to program one day... when I have some time.

A 16-bit address bus would be more of a problem. It would limit you to 64K address space. I'm not sure if the 680x0 is capable of running on a "narrow" address bus in the same way it does a data bus.

[Karlos]

Well... obviously apart from all the CPU's that don't... :lol:

Win   +1

The Z80 had an 8-bit data bus and 8-bit general purpose registers. Strictly speaking BC, DE and HL were not general purpose registers but register pairings of more general purpose 8-bit ones.

Although, given the the machine belongs in the age of the "accumulator", you might as well pick the A reg only and not even consider the rest :lol:

[Karlos]

Yup, the Falcon suffered with a 16bit Data bus. The address bus can't be "multicycled" like the data bus.

Amigaski would have loved it though. Half of the reason for picking the 16-bit wide bus was to simplify maintaining hardware compatibility with bits they'd inherited from the ST. You know, rather than actually make best use of the new hardware they were engineering into it.

[Karlos]

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.

[Karlos]

So far, so many versions. All this thread has demonstrated to me is that the compiler vendors are the only ones with a clear definition of the "bitness" of an architecture

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

[Karlos]

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

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