Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: sim085 on June 23, 2009, 09:53:18 AM
-
Hi,
While on these forums I learnt that Amiga was a 16bit machine. However I read this on wikipedia:
"While the M68k is a 32-bit processor, the version originally used in the Amiga, the 68000, has a 16-bit external data bus so it must transfer 32 bits of data in two consecutive steps, a technique called multiplexing — all this is transparent to the software, which was 32-bit from the beginning. The original machine was generally referred to in the press as a 16-bit computer;"
So does that make Amiga a 16bit machine or a 32bit machine? Considering that the software was written as if for a 32bit machine.
Regards,
Sim085
-
Interesting question...
I would call the A1000, A500, A600 and A2000 16-bit machines as they have a 16-bit data bus. Their architecture is 16-bit as well.
The AGA Amigas are 32-bit as they have a 32-bit data bus. I think the AGA chipset also makes use of a 32-bit data bus, making these models true 32-bit.
I don't know how to classify the A3000. I think it had a 32-bit data bus, but the chipset only used 16-bit.
The 68k CPU used to be called a 16/32-bit CPU, so maybe one could call the non-AGA models as 16/32-bit computers, even though it sounds clumsy.
Cheers!
Edwin
-
And now you know where the Atari ST (Sixteen/Thirty-two) got its name from. :)
Generally, though: 68000/68010 = 16bit, >=68020 = 32bit.
-
well, the 68k has a 16 bit data bus, internal 32 bit data registers and a 24 bit addressing...
So it all depends on how you choose your definition of 32 bit :D . I agree with Edwin, above.
I believe the 3000 did have a 32 bit data path though.
-
However was the software for all the Amigas written as if as for a 32bit machine?
-
I don't know how to classify the A3000. I think it had a 32-bit data bus, but the chipset only used 16-bit.
And we should never underestimate the chipset. See the Atari Jaguar.
-
However was the software for all the Amigas written as if as for a 32bit machine?
Unfortunately not. The worst example (in my opinion) is that in the old days some programmers treated it more like a 24bit computer (since the 68000 has 24bit addressing as chiark says), they would then use the upper 8 bits for storing other data to save a little memory. This kind of technique will generally fail on a 32bit system.
-
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.
-
All Amigas are 32-bit, end of discussion.
-
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.
That would be my definition too.
-
The GP register width is the most used definition. All amigas are 32-bit.
-
The whole thing about bits is nonsense anyway. Every computer/console has it's unique chipset with it's pro's and cons, so why talk about the bits?
I like the comparison between the Playstation 2 and the Dreamcast. While the Playstation 2 can show a lot more polygons (16 million, while the Dreamcast can only show 3 million), the Dreamcast has the trick up it's sleeve, for not rendering those polygons which aren't visible. As you see, the whole comparison becomes a lot more complicated.
Add to that how well the system can be programmed, how skilled the programmers are, and voila! There you have the end of the discussion! :)
-
@Karlos and @Piru
Thanks for the tip. So 32-bit it is :)
Edwin
-
for not rendering those polygons which aren't visible.
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.
-
I would say it is 32bit software running on 16bit hardware. If you are a hardware guy Amiga is clearly 16bit. If you are a software guy Amiga is 32bit.
-
In console gaming terms, OCS/ECS would be 16-bit, AGA 32-bit. Those terms lost their meaning with the release of the SNES/Super Famicom, but that didn't stop marketing departments from using them.
-
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.
-
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.
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.
-
In console gaming terms, OCS/ECS would be 16-bit, AGA 32-bit. Those terms lost their meaning with the release of the SNES/Super Famicom, but that didn't stop marketing departments from using them.
The SNES is dog slow, but has some nice bits like hardware rotation, which enabled it to run games like Mario Kart, Wolfenstein and even Doom (though the latter being quite ugly).
It's something that really should've been part of the AGA chipset (plus a DSP, like the Falcon had).
-
Ah! this debate brings me back to my Color Computer days! For those that don't know the CoCo had a 6809 processor that had a 8 bit Data bus and a 16 bit Address bus, so everyone debated 8 or 16? I am sure those with the Dragon know what I am talking about as the dragon was essentially the same computer as the CoCo.
Yes, its off topic...
-
Ah! this debate brings me back to my Color Computer days! For those that don't know the CoCo had a 6809 processor that had a 8 bit Data bus and a 16 bit Address bus, so everyone debated 8 or 16? I am sure those with the Dragon know what I am talking about as the dragon was essentially the same computer as the CoCo.
Yes, its off topic...
The Sega Mega Drive is stated as 16 Bit console (Actually the first 16 bit console), while the first 32 bit console is the Amiga CD32.
The Mega Drive have very similar architecture to the Amiga 500 - ~8MHz CPU, hardware sprites, soundchip etc.. The Amiga CD32 is close to the hardware of the later X68000 computers.
Commodore 64; Atari 800; Sega Master System; Nintendo NES; Apple II ---> 8 bit.
Amiga 500/600/1000/2000/CDTV; Atari ST; Sega Mega Drive; Super Nintendo; Apple IIGS ---> 16 bit
Amiga 3000/1200/4000/CD32; Atari Falcon; Sega Saturn; Sony Playstation; Apple Macintosh Quadra ---> 32 bit
microAmigaOne/AmigaOne XE/SE/Sam/Pegasos ---> 64 bit.
-
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.
-
Ah! this debate brings me back to my Color Computer days! For those that don't know the CoCo had a 6809 processor that had a 8 bit Data bus and a 16 bit Address bus, so everyone debated 8 or 16? I am sure those with the Dragon know what I am talking about as the dragon was essentially the same computer as the CoCo.
Yes, its off topic...
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.
-
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.
-
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.
-
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?
-
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? :)
-
Usually the CPU (data bus) defines whether the machine is called 16 or 32 bit (think of a PC 386DX with ISA slots - 32 bit). So all earlier Amigas (1000, 500, 2000, 600, CDTV) are 16 bit machines, later/bigger ones (3000, 4000, 1200, CD32) are 32 bit machines.
When it comes to chipsets, OCS/ECS is definitely 16 bit. AGA is partly 32 bit (graphics data), so I'd call it 16/32 bit.
However, the architecture is based on a 32 bit command set with everything appearing 32 bit wide, 32 bit software etc. So I'd call the Amiga per se a 32 bit system.
-
Usually the CPU (data bus) defines whether the machine is called 16 or 32 bit
Usually the Data bus and the general purpose registers are the same width... :D
-
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.
Thanks for the explanation :) I couldn't find such detailed info on the net.
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? :)
Yea, back in the day, the 68000 was considered a 16 bit proc. My Sega Megadrive is also labelled "16 bit".
-
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
-
Actually the first ever 32bit console is the FM Towns Marty, released in February 1993.
Not really, no. The FM Towns Marty contained a 386SX, the SX variant of the 386 had a 16 bit databus, like the 68000. Therefore, you could as well say the Sega Megadrive was the first 32 bit console.
-
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?
-
We're just arguing about what label the marketing droids slapped on the side of the box at this point.
-
So, was the 68030 powered Atari Falcon 16 bit then?
Eh? The 68030 is, (as well as the 68020) clearly a 32bit processor, no?
-
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 ;)
-
Usually the Data bus and the general purpose registers are the same width... :D
Not necessarily:
- Z80
- 68008 (!)
- 68000
- 8088
- Pentium (32 bit registers vs. 64 bit bus)
- ...
;)
-
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
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 (as they did with the proc of the CD32), because memory was expensive and nobody would buy more memory than a reduced processor could handle.
Cutting down the address bus doesn't affect the speed of the processor, so I'd still call it 32 bit.
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 ;)
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.
-
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 (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 :)
-
My GPU has a 448-bit bus, I wouldn't call it a 448-bit machine ;)
If it were being marketed circa 1990....
-
http://en.wikipedia.org/wiki/Atari_Falcon (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 ;)
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.
-edit- of course I understand that 65,535 bytes of memory is indeed not that much. I was a bit focused on the proc speed itself.
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.
You'd be surprised how easy the GPU is to program and how difficult it is to program well :)
I'd love to program one day... when I have some time.
-
If it were being marketed circa 1990....
:lol:
-
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.
-
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.
Yes yes I thought of that later. I wasn't thinking, or well, I was a bit confused with only thinking about processor speed.
-
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:
-
Not necessarily:
- Z80
- 68008 (!)
- 68000
- 8088
- Pentium (32 bit registers vs. 64 bit bus)
- ...
;)
Well... obviously apart from all the CPU's that don't... :lol:
Win ;) +1
-
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.
Yup, the Falcon suffered with a 16bit Data bus. The address bus can't be "multicycled" like the data bus.
-
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:
-
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.
-
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...
-
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.
-
Not really, no. The FM Towns Marty contained a 386SX, the SX variant of the 386 had a 16 bit databus, like the 68000.
Indeed. And the 68EC020 found inside the CD32 only has a 24bit address-bus and can't allocate more than 16Mb RAM... Get it isn't 32bit either :D So where does it leave us ? :)
:)
-
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...
The 68000 was designed to be comparable to the minicomputers of the time, like the PDP and the VAX... thus it's similarity to their architecture, including a 32bit data/address model.
-
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 :)
-
Interesting goody for Karlos: http://www.theregister.co.uk/2009/06/23/super_micro_gpu_node/
-
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 :)
I know that some Amiga magazines sold advertising space to retailers who were selling the A3000 (with a graphics card) as a "24 bit" computer... Which was interesting.
-
From Wiki:
The Motorola 68000 is a 16/32-bit [1] CISC microprocessor core designed and marketed by Freescale Semiconductor (formerly Motorola Semiconductor Products Sector). Introduced in 1979 with HMOS technology as the first member of the successful 32-bit m68k family of microprocessors. It is generally software forward compatible with the rest of the line despite being limited to a 16-bit wide external bus. After three decades in production, the 68000 architecture is still in use.
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.
-
The x86 is also a hybrid, so hybrids seem to be the norm.
Why is the x86 a hybrid? isn't it 32bit as well?
edit: ok I understand (read wiki article).
-
Why is the x86 a hybrid? isn't it 32bit as well?
edit: ok I understand (read wiki article).
From wiki
All internal registers as well as internal and external data buses were 16 bits wide, firmly establishing the "16-bit microprocessor" identity of the 8086. A 20-bit external address bus gave an 1 MB (segmented) physical address space (220 = 1,048,576). The data bus was multiplexed with the address bus in order to fit a standard 40-pin dual in-line package. 16-bit I/O addresses meant 64 KB of separate I/O space (216 = 65,536). The maximum linear address space were limited to 64 KB, simply because internal registers were only 16 bits wide. Programming over 64 KB boundaries involved adjusting segment registers (see below) and were therefore fairly awkward (and remained so until the 80386).
Latest X86 supports X86-64 (aka X64, AMD64, Intel64, EMT64) ISA i.e. X86's 64bit ISA.
-
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).
-
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?
-
Ok so what made the TI99/4A the first 16 bit micro?
Dunno. You'll have to ask whoever said it was :)
-
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
-
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...
-
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 ;)
-
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.
-
I'd say 32bit and always has been.
-
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 :)
-
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...
-
http://en.wikipedia.org/wiki/Atari_Falcon (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.
-
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 :)
-
IMHO the P4 was pretty much a monstrosity right from the start, built entirely for high clock rates on paper - performance came second.
-
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 :D