[geeks] arcade collectors?

Joshua D. Boyd geeks at sunhelp.org
Fri Jun 29 14:38:18 CDT 2001


The following should be taken with the knowledge that I've never
programmed an 8bit CPU, and the only 16bit cpu I've touched was an 8088,
and related.  All my real experience is with 32 and 64bit chips.

I did go and quickly skim 6502.org.

On Fri, 29 Jun 2001, Brian Hechinger wrote:

> i'm not hardware pro or nothin, but do your registers need to be INT wide?
> why not use 16bit INTs and 8bit regs, you only put stuff in regs if a) they
> are 8 bit and b) you have an immense need to.  besides, if this thing is 6502
> based, i thought regs were implemented in RAM, so you could therotetically have
> 16bit regs on an 8bit CPU.

In every CPU I've ever programmed, you can only do operations when at
least one thing is in the register.  For instance, you can't add two
numbers from memory and store the results in memory.  Rather, you can add
one number from memory, and one from a register, and store the results in
a register.  But, maybe the 6502 is different this way.  As I said, I've
never programmed it.

After reading the 6502 docs I could find, I'm struck that it used 8bit
instructions.  Maybe this is what defines the size of a CPU.  But that is
8bits for the instruction itself, not the args (RISC on the other hand
will usually use 32bits for everything about the instruction, not just the
instruction code itself).  Interestingly, you can't jump to the last byte
of a page.  Anyway, the 6502 has two registers.  It also seems to have a
stack.  The stack pointer is 8bits.  It appears that in every way possible
this is an 8bit machine.

One thing that was interesting (assuming that I read it correctly) is that
the CPU can sorta directly address 64k of memory.  But, it takes two
instructions to use access stuff outside the current least significant
8bits instead of one.  But, I just skimmed the docs, so I could be wrong
about that.

The bit count of the CPU and the INT size aren't always the same.  For
instance, some modern machines (or is it just the software on the
machine...) consider INTs to be 32bits despite having a 64bit register
size.  I think that the only way this would be worth considering is when
it makes things easier (which is why some compilers do it for
compatibility), or when you can easily use half registers.  For instance,
it is easy to store and treat seperately two 16bit or four 8bit ints on an
x86 chip.  This is because there are directions that access the different
parts directly without effecting the rest, like a 16bit add that just adds
the bottom 16bits or a 32bit reg (the do a bit roll and add again to add
the top 16bits).

However, I've never seen an instance where BIT count was less than INT.
It would make things rather difficult I'd think.
 
> or you could fake 16bit INTs in software, but that would probably cause
> obnoxiously slow performance.

I rather suspect that is what they do.  If you are just doing small
arithmatic work it wouldn't be so bad except when you numbers are
threatening to carry.
 
> i could swear that most machine have instruction and mem sizes that differ, for
> example 32-bit CPU with 64-bit mem addressing, could you actually do 64-bit
> INTs on something like that?

I don't know what CPU can do 64bit mem addressing.  The PPro and better
chips use s 36bit segmented memory scheme.  I don't know what Sparcs do.
I think that the 6502 just has to do everything through paging and
software bignums, just like a pentium dealing with longs.

--
Joshua Boyd





More information about the geeks mailing list