Ok, I have a subject that turned to be more complicated than I previously anticipated. The case is that I happily specified byte memory access instructions for my 16 bit based architecture. Now I found that implementing them in hardware may be a lot more difficult than I thought.

16 bit memory reads and writes are not problematic because I do not allow unaligned accesses and the compiler knows it. So all word (16 bit) accesses are only allowed on even addresses and can be done with single memory read or write operations. Pointers to data memory refer to bytes, so in this case it is just a matter of ignoring the the least significant bit of the address.

However, I'm unsure about what to do for byte memory accesses:

I think reads are relatively easy because I can read the full 16 bit aligned word, then discard the upper or lower data byte depending on the original address alignment. I think this can be done easily in hardware.

But how do I implement writes?. Should I perform first a word read (16 bit) , then set the relevant byte (either high or low, depending on the address), finally perform the aligned write of the 16 bit data with the modified byte?. That seems to me complicated and expensive, possibly requiring extra microcode instruction cycles. Is there a better way?, what's the usual approach?

Thanks

Joan

I think it's normal to have byte-enables on the RAM, so you can write to upper or lower half in the case of a 16 bit wide RAM. You still need to do the alignment but it avoids a RMW access.

I've a feeling hoglet might have written a shim which does the RMW access, for the "matchbox copro" board which has a nice big FPGA and a big fast RAM but which lacks the signals to do sub-word accesses. But I might be wrong!

Hi Ed, actually, shortly after posting the question I kind of realised this was the way of doing it. So if I understand it correctly, I suppose that given my total 64 Kbytes data address space, I can use two 32K x 8 memory chips, to store the low and high bytes respectively of any given word, and then just enable one the chips depending on what I want to do, which will not affect the other half. That makes total sense!

Joan:

You will also have to decide whether you want the byte on the high memory device to stay in that byte lane or move down to the lower byte lane. IOW, does the processor do the swapping of the byte lanes or is it done by external logic.

Loading a byte would naturally place it in the lower half of a 16-bit register. Similarly, storing a byte would naturally take it from the lower half of the register. A problem arises for either the processor or the memory to transfer that data from / to the byte lane used when reading / writing to the pair of memories.

(Yes, a pair of x8 chips should do the job. But also, I think you'll find that x16 chips have UB and LB inputs to control the byte lanes: "AS7C38098A. 512K X 16 BIT HIGH SPEED CMOS SRAM. 1. FEATURES ... LB#. Lower Byte Control. UB#. Upper Byte Control.")

Hi Michael,

The cpu is 16 bit only with no specific 8 bit ALU operations, so all 8 bit memory data goes to or comes from the lower half of registers and internal buses. The plan is to look at the address least significative bit. The storage convention is little endian so this means that everything with a 1 in the address goes to the 'hi' memory side and must be 'shifted' there when storing, and vice-versa when loading. Also, depending on the instruction, a sign extend (to 16 bit) may be required after loading. The plan is that the sign extension will be also done by the memory control hardware.

Hi Ed, thanks for that. I haven't understood it that way. Good to know

Joan:

Since you intend on having your memory interface HW take care of these issues, then a look at the 8086 processor's byte handling logic would be useful. If my recollection is good, those circuits would be appropriate for your architecture.

I will definitely try to find that. Thanks for the pointer !

Joan:

I downloaded the manual using the following link:The_8086_Family_Users_Manual_Oct79.pdf. Chapter 4 has a reasonable discussion of the memory interface implementation required for the external components. (Big, real big file: 60+MB)

Internally, the 8086 duplicates outgoing bytes on both halves of the data bus, and moves the incoming byte from the upper half to the lower half. These actions should enable the behavior you described above for byte-sized data in your 16-bit architecture.

Thanks for the link Michael! That's page 244 of the PDF, I reckon.
http://bitsavers.org/components/intel/8 ... f#page=244

Edit: oops, corrected, that's page 244, and also for an intro, page 28

Edit: perhaps see page 254 and thereabouts, for the BIU and the BHE signal.

WOW, the whole document is quite a lot of information, thanks to both for that. So far I started reading the specific pages where the "memory bank selection" and the /BHE (combined with A0) signals are described, which is useful. I think some of it is more complex than what I will need because if I understand well, on the 8086 there is some multiplexing going on between the address and data buses that I will not do, and the processor is able to read unaligned 16 bit values, which I won't support either. But that's definitely useful to learn the concepts.

Also do you want a little endian or a big endian format?
A real 16 bit computer did s not use bytes other than a PDP 11,
but rather has a A front panel with blinking lights. Life was simple with
one data size and 2 addressing modes, direct and indirect.
Depending on the use a computer, byte swap and masking might all be needed.
I am thinking FORTH here,but it is been a while since I used it.
Any how hardware to read or write bytes, just needs a BYTE control ,
READ/write and a VALID memory control. I favor the the 6800/6502 memory control
setup with a 4 phase clock. The only reason the 16 bit computers had weird bus signals
is to fit in a 40 pin dip.