Why the 68000 is not 32bit.

For James Ross and Simon Harris. Your argument is remarkable because you have, pretty much, described why your subsequent argument is not valid. You begin by delineating a prescient explanation of exactly why what the user sees /does not mean anything/ and the reason is the one you gave: What it can be made to /look like/ to the user does not matter. What matters is what the CPU does at an operational level. After that, the higher layers can be made to /look like/ anything you want.

What you can do on, say, a 6502, is have code like this:

CLC
LDA augend
ADC addend
STA sumtot
LDA augend+1
ADC addend+1
STA sumtot+1
RTS

augend .word $8328
addend .word $abfd
sumtot .word $0000

Oh look at those 16bit words!

Look at the fact it summed a 16bit value!

Tell yourself the truth: They are NOT 16bit words are they?

The fact it is /presented to the programmer as if a 16bit value/ is not relevant, is it?

You could just as easily have .dword .qword directives, couldn't you?

You could have assembly lines like:

.dword $5629abd5, $4c8a9f5c

Is the 6502 a 32bit CPU because you can have assembly instructions which will present RAM contents as if they are 32bit?

NO!

It makes no difference.

Why?

You know why.

It makes no difference because the 6502 is still 8bit no matter how many bits of notional representation you have.... which can be extended arbitrarily. It is STILL 8bit because what it /looks like/ to the user or programmer is IRRELEVANT. It's irrelevant because what it looks like to the programmer is NOT what happens operationally on the CPU. The CPU remains 8bit even if you have 128bits of assembly language representation.

The flaw in your argument is your desire to pass of pairs of 16bit values expressed notionally as one 32bit value as somehow changing the facts of the underlying architecture. It no more does that than a .word directive on a Commodore 64 assembler does that.

"however wide their data bus have opcodes that can work on 8,16 or 32 bit values"

No. It can't. That's the point.

1st: Opcodes don't DO anything. An opcode isn't a functional thing. It isn't a piece of hardware. It's an abstract notional entity.

The only relevance it has to what the bit rating of the CPU is the size of the opcode in bits which, on the 68000 is 16, because the 68000 is a 16bit CPU. The 68000 has 16 bit opcodes. So you're back to where you started again: It is like this because it is, at most, 16bit.


Also..... the whole point of your sentence is your desire to actively try to push this whole argument out of the realm in which it is situated, in the actual corporeal world on hardware which can be touched and weighed and Into the realm of pure notion which isn't real, it's just in your head, then you have to try to argue that the reality is irrelevant compared to whatever is in your head.

You have to accept that argument has no credibility because clearly how it looks to you /in your imagination/ is NOT what is important.

By your own initial gambit you have already accepted it can be made to /look like/ anything you want.

You can easily theorise about an imaginary chip with a few machine code instructions which is an 8bit CPU with up to 16 instructions indicated by the top four bits of each 8bit instruction word. You can imagine the lower four bits are the number of 8bit machine words to pull through the ALU. A bit like a vector processor. It would mean you could..... using your argument...... declare it to be a 128 bit CPU because you will have microcoded instructions which start processes which act on up to 16 successive 8bit values IN SEQUENCE.

Surely you can see clearly why that is a false premise. Starting a production-line process which can theoretically operate on arbitrarily long series of 8bit numbers tells you what it really says: That these operations are occurring on an 8bit micro.

If I do something like this:

LDX bytes
loop:
CLC
LDA $1000,X
ADC $1100,X
STA $1200,X
LDA $1300,x
ADC $1400,X
STA $1500,X
DEX
CPX #$FF
BNE loop
RTS

I have thus set up a piece of assembly code which operates on an arbitrary number of bytes up to 256.

Does this imply the 6510 is an 2,048 bit CPU?

No. Obviously is does not and the mere suggestion it does is clearly silly. It is NOT a 2,048 bit CPU because it only operates on 8bits at a time and nothing you can do programmatically changes the fact. No argument about having .word assembly directives changes the fact either. You know for a fact those "arguments" are not relevant. There is nothing any programmer or assembler can do to change the fact the 6510 is 8bit. No number of successive 8bit operations and no amount of representing larger than 8bit values in an assembler.

OK. I want to take that one more step before relating it back to the 68000.

Imagine I did this instead:

CLC
LDA augend
ADC addend
STA sum
LDX 8bit
BEQ end
LDA augend+1
ADC addend+1
STA sum+1
end
RTS

augent .word $1234
addend .word $5678
sum .word $0000

So.... what does that do?

Well, it does this:

That program will do one of two things. It will Either sum an 8bit value OR if a flag is set it will continue to add two more 8bit values with carry thus creating an 8bit pair which can be presented to the user as a single 16bit value.

Now..... did that make the 6510 16bit?

Obviously NO! So why did I do that? It just happens to be Exactly how the MICROCODED 68000 actually works.

If I write a 68000 instruction in assembly:

add.w d0,$1234

It is assembled as:

00001000 D1
00001001 78
00001002 12
00001003 34

Before moving on from that: Anything else you notice about it?

The memory addressing is Not 32bit. It is not even 16bit. It is 8bit. The Motorola 68000 was released in 1979. It many ways, for example instruction timing and memory addressing, it behaves more like an 8bit CPU than a 16bit CPU. Anyway.... I digress.

On another tangent, look at the branding too: 68000. It's great isn't it? What if they /called it/ the 6900? It isn't irrelevant to point out just how easily people's brains are hijacked by cool branding. The 68000 definitely does have cool branding and great marketing and a great public image. If it was /called/ the 6900 then for no reason except having 4 numbers in it name it doesn't /look/ quite so 16bit anymore does it? This is psychological. 4 digit names are more highly correlated with 8bit CPUs and 5 number names to 16bit and above. It's a statistical correlation which influences notional thinking. You can do a lot with branding as Motorolas then marketing manager did. 68000 sounds far cooler, bigger, cleaner and more sophisticated than 8086 but it /means/ nothing. 68000, being a cool, big, clean number doesn't mean anything but it bends people's minds anyway.

Back to the 68000 as it is......

If I write:

add.w #$7654, d0

It is assembled as:

00001000 0640
00001002 7654

If I write:

add.l #$76543210, d0

It is assembled as:

00001000 0680
00001002 7654
00001004 3210

What can you say about the high nibble of the low byte of the machine code for the instruction?

You can say that bits 2 and 3 state how many 16bit bytes to load after the instruction.

In fact, to be really pedantic about it, it's log_2 of how many 8bit bytes have to be loaded.

2^0 = 1
2^1 = 2
2^2 = 4

This is consistent with:

add.b #$76, d0

Which assembles to (can you guess?):

00000100 0600
00000102 0076

So.... what's consistent about all three?

1. The instruction code is always 16 bit.
2. The operands are always measured in 16bit clusters. Even when you choose an 8bit value.
3. Each of those 16bit parts must be 16bit aligned: They cannot begin on odd numbered memory addresses. They must begin on 16bit aligned RAM locations. Not 8, not 32, but 16.

Why? Because the 68000 is 16bit microprocessor.

So, what happens then when you use:

add.l #$76543210, d0

32 bit somehow?

No.

It works like the assembly code I wrote earlier.

What happens is this:

1. It first takes a 16bit instruction code from RAM.
2. It then decodes that instruction.
3. The instruction code incorporates in it a code to instruct the microprocessor to then take in succession each of two 16bit values in RAM following the instruction and feed them into the ALU, one after the other, and add each, one at a time, to each of the two 16bit on chip RAM locations reserved for the d0 register space.

So... AT NO POINT DOES ANYTHING 32BIT OCCUR.

Let me say that one more time:

AT NO POINT DOES ANYTHING 32BIT OCCUR. Not even if you use .l instructions.

So, add.l doesn't get you anything. It is just a prompt to the CPU to perform two 16bit operations one after the other.

It does this because a 68000 is a 16bit CPU. What a disassembly can make it look like clearly didn't change anything just like .word directive on a 6510 or word-size memory dumps on a 6510 do not make the 6510 an 8/16 bit CPU. The programmer representation is inadmissible because you can make it anything you like and it doesn't change the underlying reality. The ground-truth is still the same. 68000: 16 bit instruction length. 16 bit ALU 16 bit data bus. 16 bit aligned assembly language.