Who's interested in wide-byte 6502 variants like 65Org16?

[barrym95838]

randallmeyer2000 wrote:

... So data bus is generally the width of the accum. and/or working registers. That makes the most sense anyway; otherwise bottlenecks ...

Well ... they can be different, and there are plenty of successful designs that deal with the differences. What we mean in this thread is the native size of a memory cell to which a native address points. If an address points to the first of a group of four bytes, and your register is four bytes wide, then it doesn't really matter how many bus transactions it takes to transfer the data, or even how many bits are in each byte, at least for a programmer who wants to store/load a register to/from memory.

If the data bus width matches the register width, then Bob's your Uncle. If it doesn't, then other things have to happen, but that's more of a hardware issue than a software issue. That's why an 8xxx machine language binary can run unchanged on an 8-bit data-bus 8088 or a 16-bit data-bus 8086. The same could be said for a 68k binary running unchanged on a 68008 or a 68000. The performance may differ, but the result is the same (assuming that performance isn't a significant factor of the result).

Mike B.

[Arlet]

barrym95838 wrote:

The instruction sets of these processors can still deal with groupings of 8-bits, but not without some effort, since they treat memory as an array of "wide" bytes, usually of 16 or 32-bits each. So, using my 65m32 as an example: if I want to load 8-bits from memory, I have to find the address of the cell containing those 8-bits, load the 32-bit cell containing those 8-bits and mask-shift to get those 8-bits in the least-significant end of my register, assuming that's where I want them. To do a general-purpose store of 8-bits to memory, I would have to do a load-mask-shift-merge-store.

It may be instructive to look at the way the older ARM architectures dealt with this, since they nearly exclusively worked with 32 bit data. The only 8 bit instructions were LDRB (load byte), and STRB (store byte). Loading a byte is just the same as loading a 32 bit word, except the hardware provides a rotate in steps of 8, and a mask, which shouldn't be too complicated (except for dealing with the extra logic delay). On writing a byte, you have to provide a similar rotate to move the byte in the proper position, and then use the appropriate byte lane strobe to only write that byte to memory. Most wide memories will have separate enable signals for each 8 bit part of the data bus.

Another thing the ARM did was a trick with unaligned 32 bit reads. The hardware would load the data, rotate it such that the byte on the unaligned address would be on the right, just as it would do for a LDRB. But then it wouldn't do the masking, so you'd still have the whole 32 bits, but rotated.

All of this shouldn't be too hard to implement, and still provide some useful ways to deal with 8 bit data.

[barrym95838]

@Arlet: But "unaligned" is not in the 65m32's vocabulary, since it only addresses words. If I changed it to address bytes, I would lose 75% of my address space, unless I used different addressing for opcodes that specifically targeted 8-bit bytes. Then, bytes could only be addressed in 1 GW out of the possible 4 GW memory map.

I'll have to consider whether or not hardware support for 8-bit bytes is worth adding another "wart" to my architecture. I'm leaning towards "no". Dieter convinced me to add one "wart", allowing automatic hardware assist for long-addressing (using a magic-value short address to trigger a long address fetch), but he had to really sell it, because I can be a stubborn SOB. Besides, I've always thought that 8-bit bytes were a stupid idea anyway ... they should have been at least nine, or better yet, 10-bits. I guess that means I can be an eccentric SOB too!

Mike B.

[BigEd]

My inclination is certainly to keep running with the wide-byte idea - partly because everywhere else you can find the conventional idea of byte-addressable memory, and partly because word-addressable memory has a venerable tradition in the history of computers. The size of a character has varied from 6 to 8 bits (at least) and the size of the most finely addressable unit (the cell, or byte as we say here) has varied from 1 bit up to ... well 32 certainly.

(Just to note: we have several widths in play, which are variables to anyone designing a CPU but constants to anyone using one. The width of the registers, or the accumulator. The width of an instruction. The width of an address. The width of the physical bus to memory. The width of the smallest addressable memory unit. I think I'm right in saying these are all different. Which is why people sometimes get into arguments about whether, say, the 68008 is an 8-bit, 16-bit or 32-bit machine. The answer is, it depends on what you mean. The 68008 has an 8 bit path to memory, but fetches 16-bit instructions. The registers are 32 bits wide, as are addresses. But the CPU can address each 8-bit byte of memory - that's the cell size - and it has instructions to operate on 8 bit, 16 bit and 32 bit sized data. The address bus is 22 bits for some models, and more for others.)

(A more conventional term for our wide-byte machines is word-addressable machines.)

[White Flame]

Just another note: Add the ALU to the list of widths as well, as most popularly z80 and 68000 have differences between that and their register width.

[randallmeyer2000]

"My cat's breath smells like cat food."~ Ralph, a character from the Simpsons.

I feel a bit like Ralph, in this thread. But I almost said something smart.

Seems the nibble was obsolete the day it was invented; in true American/Anglo fashion, everything must be "super-sized" (well, I guess the Turks, too, built a big gun, shortly before the walls of Byzantium fell?). So, can we call "wide-bytes" something else? Like Gulp=16 bits; Big-gulp=32 bits? Bolus = 64 bits? Then the contrarians among ye, needn't insist that "a byte should be 10 bits...".

[sheepishly admitted] I haven't checked the online catalogs to see if "words" can be greater than 8 bits, i.e. one true-byte. I'll check the RAM pdfs, and perhaps respond with a thoughtful thread, instead of the above (i.e. above trash).

So, FPGAs are an IC, no? And they must address RAM, no? So, it's not merely "fancy-pants coding methods", but some real hardware stuff, right? I thought so.

Also, thanks for reminding me; I have an ARM book somewhere in my library; I must dig it out and peruse it.

So, Barry, or Ed, or anybody else "going wide"; any plans to sell your design to WDC once you get it running? They are a fabless semiconductor company, and could find the fellas to make it "real"! Keep the hardware relevant and updated, and you can keep the syntax alive! (If you can figure out how to run an iphone with a 6502, you'll send this uproc. into the next millennium, and beyond! Do I exaggerate? OK, maybe a little.).

[Tor]

On a couple of minicomputer architectures I worked with the nomenclature was nibbles (4 bits), bytes (8 bits), half-words (16 bits), words (32 bits), double words (64 bits), and, on VAX IIRC, quad words (128 bits).

[GARTHWILSON]

AFAIK, 4 and 8 bits were always nybbles (or nibbles) and bytes, but then I would think words is next at 16 or 32 bits and long words at 32 or 64 bits.

[Tor]

Well, 'long' is a bit of a problem - it's usually a software type (as in 'long int' in C), while 'word' is usually applied to the hardware. As in 'word size'. They are of course two sides of the same coin, but still 'long' belongs in the 'int' or 'integer' or 'cardinal' software camp while 'word' is in the hardware camp. Not that there haven't been programming languages mixing all of this up, but still.. so I would say there are 'long ints', and 'double words'.

In the list I made in my previous post the architectures in question were 32-bit systems, so they had a 'word size' of 32 bits. Thus it made sense to use 'half-word' for 16 bits and 'double word' for 64 bits. But those same companies produced 16-bit systems before that, and then their systems had a 'word size' of 16 bits. In C (before 1991 or so[*]), 'int' was meant to be the 'natural word size' of the architecture, and could thus be 16 bits or 32 bits (VAX: 32 bit word size => 32 bit int size). 'long' or 'long int' would be double that. I don't think 'int' ever was 8 bit, because C originated on the PDP (IIRC around the time Unix was ported from the PDP-7 (18 bits) to PDP-11 (16 bits).
So that's why I feel itchy about mixing 'long' and 'word' together

-Tor

[*] What happened in 1991? Well, some companies came together and produced a whitepaper where they tried to standardize on int as 32 bits, long as the size of a pointer, long long as 64 bits, and so on. Not that it fully caught on, Windows didn't completely follow, for example. But it dominates the Unix world.

[rwiker]

See http://www.catb.org/jargon/html/N/nybble.html for names of a few more word sizes (although I cannot honestly say that I've seen any of those in actual use).

[BigEd]

Notably the Z80's ALU is only nibble-wide. It doesn't hurt because the micro is clocked several times faster than memory, and internal byte wide actions can take two ticks.

For me, a word is the minimum addressable unit: what gets fetched and written, how many new bits you get when you increment an address by one. A byte is the size of a character, when handling strings. In the old days, words went up to 60 bits at least (CDC 6400 & Cray) and characters were commonly 6 bits.

[Edit: OK, that definition doesn't really work, as all common microprocessors allow for byte addressibility but are often unmistakeably 16 bit or 32 bit architectures.]

For more on memories, see
http://edwardbosworth.com/My5155Textboo ... 08_V06.htm

To simplify the implementation, the wide-byte 6502 variants I was thinking of for this thread do not pack multiple characters into a word: they operate on words and only on words. Of course it's often suggested that it would be an obvious or even necessary improvement to add support for byte-wide operations. (It would indeed be an improvement for the user, but extra complexity for the implementer and for the tools.)

On the topic of selling a wide-byte design, I believe making chips is impractical - there's nowhere near the volumes to make it economical. However, two or three things can be done:
- sell a preprogrammed FPGA, of the type which has on-chip configuration memory
- sell a preprogrammed configuration memory suitable for some particular FPGA
- sell a board with both FPGA and memory on it, preprogrammed with the wide design.

In all cases, that could be a hobbyist - one of us - selling more or less at cost, or selling with a bit of a markup to cover breakages and rejects and unsold parts. Or it could be someone with a slightly more commercial angle, covering the cost of their time and business expense, selling for say twice as much. Say $10 for the memory or $100 for the board, give or take a factor of two.

The difficulty which arises immediately is that you'll never get two people to agree on what the chip should do or what the pinout should be. The only solution is that one person takes on the role of deciding, designing, testing and selling. As yet that person hasn't stepped up - not too surprising for a couple of reasons. One is that the volume is very small and very uncertain, and another is the demotivating effect of negative commentary.

So, the way ahead today, as yesterday, is that interested parties will buy their own FPGA boards ($20 to $2000) and load them up with an existing core, or their own experiments. It's not actually at all difficult to program up a board, you just have to start by choosing one. We have a thread on that:
viewtopic.php?f=10&t=1787

(Please start a new thread if you have a new question to discuss!)