Jump to content
IGNORED

Is the 68000 unfairly labeled a 16-bit CPU?


Recommended Posts

32-bit internally, limited to 16-bit data throughput.

 

http://www.sega-16.com/forum/archive/index.php/t-4330.html

 

Actually, a little less simple than that. It only had 16bit ALUs. The ALU is what determines the CPUs bit-ness.

 

https://en.wikipedia.org/wiki/Motorola_68000

 

it is generally software forward-compatible with the rest of the line despite being limited to a 16-bit wide external bus.

 

and that's as far as I can go with pretending to know what I'm talking about microprocessor architecture

Link to comment
Share on other sites

The Motorola user manual for the chip is called :-

 

"M68000
8-/16-/32-Bit
Microprocessors User’s Manual"

 

Quoting directly :-

"1.1 MC68000
The MC68000 is the first implementation of the M68000 16/-32 bit microprocessor
architecture. The MC68000 has a 16-bit data bus and 24-bit address bus while the full
architecture provides for 32-bit address and data buses. It is completely code-compatible
with the MC68008 8-bit data bus implementation of the M68000 and is upward code
compatible with the MC68010 virtual extensions and the MC68020 32-bit implementation
of the architecture. Any user-mode programs using the MC68000 instruction set will run
unchanged on the MC68008, MC68010, MC68020, MC68030, and MC68040. This is
possible because the user programming model is identical for all processors and the
instruction sets are proper subsets of the complete architecture."

 

tl;dr version: Its 8-bit, 16-bit and 32-bit :lol: :P

Link to comment
Share on other sites

Oh! Oh! I l know one other thing about this processor, which was used in the early Macs as well as the Sega Genesis, Amiga, Atari ST, Neo Geo, and more.

 

http://lowendmac.com/2015/32-bit-addressing-on-older-macs/

 

System 7 was Apple’s first operating system to support 32-bit addressing. This broke through the 8 MB memory barrier on all Macs not based on the 68000 CPU. With 32-bit addressing enabled, many models can support 64-128 MB of memory – and a few as much as 256 MB.

Without enabling 32-bit addressing, the Mac OS only has access to 8 MB of memory. Anything beyond that is reported as used by the system.

Link to comment
Share on other sites

The 68K has instructions to multiply two 16-bit numbers to create a 32-bit number, or divide a 32-bit number by a 16-bit number; can't do that with a 16-bit instruction set.

 

The 6809 has a 16-bit multiply; can't do that with an 8-bit CPU.

 

Chalk it up to Motorola being different...

  • Like 2
Link to comment
Share on other sites

The Motorola user manual for the chip is called :-

 

"M68000

8-/16-/32-Bit

Microprocessors User’s Manual"

 

Quoting directly :-

"1.1 MC68000

The MC68000 is the first implementation of the M68000 16/-32 bit microprocessor

architecture. The MC68000 has a 16-bit data bus and 24-bit address bus while the full

architecture provides for 32-bit address and data buses. It is completely code-compatible

with the MC68008 8-bit data bus implementation of the M68000 and is upward code

compatible with the MC68010 virtual extensions and the MC68020 32-bit implementation

of the architecture. Any user-mode programs using the MC68000 instruction set will run

unchanged on the MC68008, MC68010, MC68020, MC68030, and MC68040. This is

possible because the user programming model is identical for all processors and the

instruction sets are proper subsets of the complete architecture."

 

tl;dr version: Its 8-bit, 16-bit and 32-bit :lol: :P

 

And the 80386SX also is 32-bit internal, 16-bit data bus, and 24-bit address bus. Same numbers.

  • Like 1
Link to comment
Share on other sites

The 68K has instructions to multiply two 16-bit numbers to create a 32-bit number, or divide a 32-bit number by a 16-bit number; can't do that with a 16-bit instruction set.

 

The 6809 has a 16-bit multiply; can't do that with an 8-bit CPU.

 

Chalk it up to Motorola being different...

 

And that step of combining the two 16-bit words is the only distinction that I can see between the two chips in terms of bit rating.

 

Almost sounds like a technicality to me.

Edited by Nebulon
Link to comment
Share on other sites

The 68K has instructions to multiply two 16-bit numbers to create a 32-bit number, or divide a 32-bit number by a 16-bit number; can't do that with a 16-bit instruction set.

Really? Best tell that to the Siemens 166 programmers who use the 16x16 multiply, 16 by 16 division and 32 by 16 division opcodes then.

 

The 6809 has a 16-bit multiply; can't do that with an 8-bit CPU.

Really? Best tell that to the AVR and HCS08 programmers who use the 8x8 multiply opcodes then :P.

Link to comment
Share on other sites

Really? Best tell that to the Siemens 166 programmers who use the 16x16 multiply, 16 by 16 division and 32 by 16 division opcodes then.

 

 

Really? Best tell that to the AVR and HCS08 programmers who use the 8x8 multiply opcodes then :P.

 

I was thinking contemporary, those CPU's are more modern.

 

Interesting thing about the Seimens 166 is that it's an 8/16-bit processor with 32-bit instructions, reminds me a bit of the Hitachi 6309 upgrade for the 6809.

The opposite combination is also possible - the Sega Saturn had a 32-bit CPU with 16-bit instructions.

Link to comment
Share on other sites

Motorola itself referred to it as a 16/32 because the ALU was 16bit, using it on 32bit quantities took twice the time than on 16bit, the 68020 (Motorola first full 32bit at the ALU level) instead did not behave like that.

Check the 68K immediate instructions timings here:

https://wiki.neogeodev.org/index.php?title=68k_instructions_timings#Immediate_instructions

 

The 68K instruction set is full on 32 bit, internally though not so much, even wikipedia got this right on the first paragraph:

https://en.wikipedia.org/wiki/Motorola_68000

(and I just found out there was a 68012 with a 31bit address bus .... one really never stops learning)

 

BTW because of that (double the cost for 32bit support) many programmers of the time limited themselves to manipulate 16bit quantities whenever possible even if 32bit operations were supported, a little bit like later on the N64 even if it used a real 64bit CPU in the end programmers mostly resorted to instructions handling 32bits as those were both faster and more compact.

In both cases (68K and MIPS VR4300 [for the N64]) the data bus was also half the width (16bits and 32bits respectively) making even the fetching of data of double width twice as expensive .... so twice the memory cost and around twice the execution cost .... one result ... don't use it unless there's no alternative/hack that you can live with.

Link to comment
Share on other sites

 

And the 80386SX also is 32-bit internal, 16-bit data bus, and 24-bit address bus. Same numbers.

 

Back in the day, I used to explain to "PC people" that the processor in my Amiga 1000 was similar to an 8 MHz 386sx. Of course the Amiga was more capable in the areas of graphics and sound, but that was the easiest way to "dumb it down".

  • Like 1
Link to comment
Share on other sites

Motorola itself referred to it as a 16/32 because the ALU was 16bit, using it on 32bit quantities took twice the time than on 16bit, the 68020 (Motorola first full 32bit at the ALU level) instead did not behave like that.

Check the 68K immediate instructions timings here:

https://wiki.neogeodev.org/index.php?title=68k_instructions_timings#Immediate_instructions

 

The 68K instruction set is full on 32 bit, internally though not so much, even wikipedia got this right on the first paragraph:

https://en.wikipedia.org/wiki/Motorola_68000

(and I just found out there was a 68012 with a 31bit address bus .... one really never stops learning)

 

BTW because of that (double the cost for 32bit support) many programmers of the time limited themselves to manipulate 16bit quantities whenever possible even if 32bit operations were supported, a little bit like later on the N64 even if it used a real 64bit CPU in the end programmers mostly resorted to instructions handling 32bits as those were both faster and more compact.

In both cases (68K and MIPS VR4300 [for the N64]) the data bus was also half the width (16bits and 32bits respectively) making even the fetching of data of double width twice as expensive .... so twice the memory cost and around twice the execution cost .... one result ... don't use it unless there's no alternative/hack that you can live with.

 

Well, we know that it executes 32-bit code fine, seeing as AmigaDOS is a 32-bit O/S.

 

I wonder how the 68012 deals with the missing bit... (and I wonder who decided on 31 bits). ;-)

Link to comment
Share on other sites

 

Well, we know that it executes 32-bit code fine, seeing as AmigaDOS is a 32-bit O/S.

 

I wonder how the 68012 deals with the missing bit... (and I wonder who decided on 31 bits). ;-)

No missing bit. Exactly like the 68K doesn't care for the high 8 bits in a An register, the 68012 doesn't care for bit 31 .... doesn't care mean it does not get onto the bus as there's no pin for it.

As to who decided I believe it was the other way around, the packaging/number-of-pins is what costs a lot and there are only so many options, so they picked whatever made sense wrt costs, and rather than expose the full 32bit address space (4GB access) they decided that 31bit (2GB) was enough and instead use that 1 saved pin for the RMC signal to enable support for multiprocessor configurations. Remember that in those days 4MB of on-board RAM was already a whole lot all the way to 1990.

[so told I've never heard of a 68012 before 2 days ago so as far as I am concerned it never existed ;) ].

BTW the price of the chip packaging/pins was so important that Sinclair launched the Sinclair QL with a 68008 (with a crippled 8bit bus), the IBM PC XT used an 8088 (crippled 8bit bus 8086), and WDC designed the 65816 (the 16bit successor to the 6502) supporting only a crippled 8bit bus .....so there's that.

Company do funny things in the name of saving check the Philips SCC68070 on the CDi, a derivative of the 68K with a missing AGU [the ALU that was used for address generation] hence forcing any instruction that had to perform any math on the address side to basically contend the ALU with the actual operation resulting in much longer timing for many instructions and in the end lower perf .... at least the frequency was twice as high to mask some of that but still ... penny wise pound foolish.

 

Wrt 32bit code the fact that internally the 68K needs to implement 32bit support via a 16bit ALU means that the exact same results can be obtained (mostly with the same timing) on 16bit architectures assuming enough registers ... this is getting a little academic/moot though at this point.

The 68K has a 32bit ISA implemented via an hidden 16bit ALU, if Motorola never told us that we would not have known and simply stated it was a 32bit processor (because of the ISA) and have been amazed on how they more than doubled the perfs on the 68020.

 

So told most of the code written back in days because of speed/size considerations limited itself to 16bits operations whenever feasible/possible hence why that whole generation even if it used a 68K was named the 16bit generation (AtariST, Amiga, Megadrive).

I can't remember if the original Mac also based on a 68K was marketed as a 32bit system ..... or what about the Sun-1 also a 68K machine .... in this case Motorola silence would have been golden [yes perf would not have been up to par with an equally matched 16bits of the time like say an 8086 at 10/12Mhz or maybe a 80286 but hey at least we wouldn't be having a "nomenclature-gate" on our hands]

Link to comment
Share on other sites

We have entered muddy waters here as to what is 8 bit, 16 bit, 32 bit, or 64 bit.

The 68K has instructions to multiply two 16-bit numbers to create a 32-bit number, or divide a 32-bit number by a 16-bit number; can't do that with a 16-bit instruction set.

 

The 6809 has a 16-bit multiply; can't do that with an 8-bit CPU.

 

Chalk it up to Motorola being different...

The 6809 has an 8 bit x 8 bit multiply... which is an 8 bit multiply.
Yes the result is 16 bit, but the multipliers are 8 bit.

 

The instruction set of the 68000 is most certainly 32 bit, but the ALU and data buss are 16 bit.
Does that make it a 32 bit processor or does the size of the ALU make it a 16 bit processor?

The Z80 can deal with 16 bit numbers but it has a 4 bit ALU. So is it a 4 bit, 8 bit, or 16 bit CPU?

The 6309 has a 16 bit x 16 bit multiply with a 32 bit result, and a 32 bit to 16 bit result + 16 bit remainder divide.

But the instruction set is 8 bit. I'm not sure if it has an 8 bit or 16 bit ALU, but the data buss is 8 bit.
I definitely wouldn't call it a 32 bit processor, but it can handle several 32 bit operations.

Like I said... muddy waters.

  • Like 4
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...