Microcontrollers memory

[nForce]

I have not see any other technical data at ROM chips.

[rrinker]

I later needed to do some assembly to speed up a mostly BASIC program on an Apple 2, the limitations of the 6502 really made me hate that CPU. 

6502 wasnt the problem, you learning BASIC as your first "programming language" was, BASIC rots brains. This fact, often mistaken for opinion, became clear to me while observing numerous programmers with BASIC background. I was happily validated later after learning It wasnt all that original either (Dijkstra said it first).

 You left out the part where the first computer I actually OWNED, could only be programmed directly in machine code with a hex keypad. Not even an assembler. Yes, I learned BASIC before I was able to buy that computer, but the first computer I was able to afford was not capable of running BASIC or any other higher level language - at least not out of the box. It only has 256 BYTES of RAM. I learned to write very efficient programs using that machine. It's that the limited registers and therefore enforced use of a stack handler in the 6502 made it MUCH harder to write the code for than if I were trying to do the same thing on the 1802. And I'm not the only one - Tom Pittman, creator of Tiny BASIC, remarked in an article that the 8080 version fit in exactly 2K. The 1802 version had 200 byes left over out of 2K, and the 6502 version, he could not get to work in 2K no matter what without removing some things.

[brucehoult]

It's that the limited registers and therefore enforced use of a stack handler in the 6502 made it MUCH harder to write the code for than if I were trying to do the same thing on the 1802. And I'm not the only one - Tom Pittman, creator of Tiny BASIC, remarked in an article that the 8080 version fit in exactly 2K. The 1802 version had 200 byes left over out of 2K, and the 6502 version, he could not get to work in 2K no matter what without removing some things.

99% of the attraction of the 6502 was that it was a somewhat usable microprocessor that cost $20 when everything else cost $200 -- and it didn't need a lot of support circuitry.

The instruction set is awful, the lack of proper registers hurts a lot (you end up treating Zero Page as a *lot* of almost-registers), and the small and very limited functionality stack was not usable for anything except actual function return addresses and temporary register shuffling.

Programs for the 6502 were, as you say, awfully big, but they did run pretty fast. For general computational code (not things like block move that the 8080/Z80/x86 specialise) I generally thought a 1 MHz 6502 would often beat a 3.25 or 3.5 MHz Z80 such as in the ZX80/81 and Spectrum.

The 8080/Z80 were better targets for C or Pascal compilers, but they were still awful!

The 1802 is clearly nicer to program, but it used a lot more clock cycles per instruction than even the Z80, while running at similar clock speeds. I'm afraid I have no idea what the price was in 1976ish. Anyone know?

[westfw]

The 1802 is clearly nicer to program

Are you kidding?  It was "nicer to program" only in the sense the architecture was so weird that there were standard APIs developed to do the "unpleasant" stuff (like some sort of stack-based procedure call.)  Sort of like writing in RISCy microcode, where each microcode instruction took 16 clocks.

I'm afraid I have no idea what the price was in 1976ish. Anyone know?

"Less than $30";   You could build yourself an entire COSMAC Elf for about $80, according to the original article:

https://www.americanradiohistory.com/hd2/IDX-Consumer/Archive-Poptronics-IDX/IDX/70s/76/Poptronics-1976-08-OCR-Page-0031.pdf#search=%22cdp1802%22
(Archives of Popular Electronics and Radio Electronics are online these days.  They're great for doing stuff like checking historical prices.)

[brucehoult]

The 1802 is clearly nicer to program

Are you kidding?  It was "nicer to program" only in the sense the architecture was so weird that there were standard APIs developed to do the "unpleasant" stuff (like some sort of stack-based procedure call.)  Sort of like writing in RISCy microcode, where each microcode instruction took 16 clocks.

I said it was slow :-)

But, yes, I stand by it looking more pleasant than the 6502 to program. Certainly it's not as nice as a modern processor, but it's not awful.

There's an 8 bit accumulator ("D") that all arithmetic goes through (as with 6502 and z80), and only via mem->acc operations (as with 6502). The memory operand can be an immediate or it can be the byte pointed to by any one of *sixteen* 16 bit pointer registers. Exactly which pointer register is not specified in the add/adc/sub/sbc/or/and/xor instruction itself, but by the most recent SEX (set X) instruction. You can also shift or rotate D by 1 bit position.

Any pointer register can be incremented or decremented as a 16 bit unit in a single instruction.  You can load or store the byte pointed to by any pointer register (specified in the instruction) to/from D, with or without incrementing the pointer. You can push or pop D to the address in the pointer register set by the most recent SEX instruction. You can move either half of any pointer register to or from D, allowing you to use them as 32 8 bit registers.

Any pointer register can be the PC, using a SEP instruction. If a function uses a different PC register from its caller then it can return simply with an SEP with the caller's PC register. That's funky, but you can deal with it.

The conditional branching is reasonably sensible, with some flags and branch on zero/nonzero/negative/positive. The only weirdness is the branch specifies an absolute address within the same 256 byte page rather than a relative address. That's annoying, but don't PIC programmers get to deal with that too?

Suppose you have two 16 bit values in memory, pointed to by registers A and B on 1802 and by zero page addresses A,A+1 and B,B+1 on 6502, and you want to add A to B.

On 1802 I get:

SEX A
LDN B
ADD
STA B
INC A
INC B
LDN B
ADC
STA B
DEC A
DEC B

All are single byte instructions, so that's 11 bytes and I think 22 instruction cycles and 176 clock cycles, 50 us at typical clock speeds.

On 6502:

LDY #0
CLC
LDA (B),Y
ADC (A),Y
STA (B),Y
INY
LDA (B),Y
ADC (A),Y
STA (B),Y

That's 9 instructions, 16 bytes, and 36 clock cycles, 36 us at typical clock speeds.

That's a pretty similar amount of pain for both CPUs in this case. As I said before, the 1802 code is generally more compact, but the 6502 code will generally run faster.

The 6502 has more zero page locations available (256 bytes) than the 1802 has registers (16 registers containing 32 bytes), but it's rare for code to need more than 16 pointers.

As the examples get bigger, I think the ability to increment and decrement the 1802 registers independently will be a lot more convenient than everything sharing Y as the index on 6502. If you have to increment or decrement the actual pointers in 6502 zero page it starts to get quite painful, at least if there can be a page crossing -- then you need "INC A; BCC .+2; INC A+1" which gets both big and slow.

If I'm writing a compiler, I'll take the 1802 any day. And I think for assembly language programming too.

[westfw]

That's a pretty similar amount of pain for both CPUs [1802 vs 6502] in this case.

Do you remember what you had to do to wrap a standard stack-based procedure call API around your 1802 code?Me neither.  But it involved dedicating one of the 16 pointer registers to the "call" "microcode" (r4?), and another to the "return" "microcode" (r5?), plus standardizing on your normal PC (R3?) (and SP.)
Even "quick" subroutines that were "called" just by changing the PC register had the weird looking:

Code: [Select]

funcret: SEP normalPC  ;; set PC back to caller code to return
func:  ;; do stuff      BR funcret  ;; done.  set up current PC to be called again and go.

[westfw]

I found some "SCRT" code for 1802 ("Standard Call and  Return Technique"?)

Code: [Select]

;*************************************************************************
;DESC: STANDARD SEP CALL and RETN
;REG USED: SP,PC,SEP CALL;,A(,RETURN,LINK & STACK
;*************************************************************************

; STANDARD CALL

EXITC SEP PC             ;GO TO CALLED ROUTINE

CALLR SEX SP             ;SET R(X)
    GHI LINK
    STXD                ;SAVE THE CURRENT LINK ON
    GLO LINK
    STXD                ;THE STACK
    GHI PC
    PHI LINK
    GLO PC
    PLO LINK
    LDA LINK
    PHI PC              ;PICK UP THE SUBROUTINE
    LDA LINK
    PLO PC              ;ADDRESS
    BR EXITC

;  STANDARD RETURN

EXITR  SEP PC            ;RETURN TO MAIN PGM

RETR GHI LINK            ;recover calling program return addr
    PHI PC
    GLO LINK
    PLO PC
    SEX SP
    INC SP              ;SET THE STACK POINTER
    LDXA
    PLO LINK            ;RESTORE THE CONTENTS OF
    LDX
    PHI LINK            ;LINK
    BR EXITR

[brucehoult]

That's a pretty similar amount of pain for both CPUs [1802 vs 6502] in this case.

Do you remember what you had to do to wrap a standard stack-based procedure call API around your 1802 code?Me neither.  But it involved dedicating one of the 16 pointer registers to the "call" "microcode" (r4?), and another to the "return" "microcode" (r5?), plus standardizing on your normal PC (R3?) (and SP.)
Even "quick" subroutines that were "called" just by changing the PC register had the weird looking:

Code: [Select]

funcret: SEP normalPC  ;; set PC back to caller code to return
func:  ;; do stuff      BR funcret  ;; done.  set up current PC to be called again and go.

I don't "remember" because I've never before today taken a close enough look at the 1802 to write actual code but, yes, looking at the detailed ISA that's exactly what I'd do.

Skipping ahead to your next message, those call and return routines are pretty much exactly what I envisioned. You seem to regard them with horror, but I see they are only 15 bytes and 12 bytes. That's only space for three or four instructions on a MIPS or ARM or RISC-V without their respective compressed code extensions and the BEAUTY of it is that you only have to have one copy of each of those for your entire program.

The main thing I'd do differently would be to not have every one of those pointed to by its own pointer register "PC" because that's not going to scale to more than a handful of such "helper functions". I'd dedicate a single PC register to *all* such helper functions (or up to 256 of them anyway) and call them by doing a load immediate into D (or some other 8 bit register) and then SEP to the helper function which would then do a switch/case into the appropriate code. That would be slightly slower, but much more expandable. Maybe function call/return are important enough to do individually, I don't know.

In RISC-V land we call these kind of special helper routines "millicode". They don't follow normal function call conventions, and can (as here) even be used to assist in function calls and returns. We use register x5 for call/return for millicode instead of the normal register x1. At the moment the main ones we have are for saving and restoring various sets of registers on function entry and exit. They use a total of 96 bytes of code, and if you repeat these 96 bytes every 2 MB of program code then you can call them with a single 4 byte instruction. Or if you can store them in the top or bottom 2 KB of the address space, or within +/- 2 KB of some fixed register (such as GP, the Globals Pointer) then that also allows calling them with a single instruction.

Another example of millicode in RISC-V land is a standard interrupt handler that saves registers, checks if a new interrupt came in while you were doing that, and does software vectoring to the appropriate handler written as a standard C function. When that returns it again checks (before restoring registers) whether another interrupt needs servicing and dispatches directly to that (what ARMs fancy newish hardware calls interrupt tail-chaining), restoring registers and returning if not. All of this happens in a couple of dozen bytes of standard software with about the same latency as a Cortex M does using hardware sequencing.

It's quite likely that we'll soon migrate transcendental functions from the C library to millicode -- at least for vector processing code. Maybe scalar too.

The DEC Alpha called a similar idea "PALcode" (https://en.wikipedia.org/wiki/PALcode) although theirs seems to always involve a privilege transition. RISC-V does that too, with the SBI (System Binary Interface), which is where things like I/O, that interrupt vectoring handler, or software TLB refilling live, but we have some that just stay in user mode too.

These are certainly *not* microcode, but they are a lower resource alternative to providing complex machine instructions or background mechanisms in hardware or microcode that traditionally perform the same tasks.

If properly designed (along with the hardware), millicode can provide essentially the same performance as hardware or microcode, but more cheaply in area and energy. In fact if you have a superscalar processor (whether in-order like the ARM A9 or A53 or SiFive 7-series or Western Digital SweRV, or out of order) then you can often run millicode *faster* than a hardware sequencer or microcode.

Anyway, I see nothing wrong with using such helper functions on the RCA 1802. You'll find 6502 code full of similar things too -- just for different things.

[legacy]

If properly designed (along with the hardware), millicode can provide essentially the same performance as hardware or microcode, but more cheaply in area and energy.

cheaply area is ok, I get it, but why cheaply energy?

*faster* than a hardware sequencer or microcode.

the traditional meaning of microcode is that given an opcode, it's decoded into an index that points to the micro-ROM, *from* where micro-instructions are then sequenced.

I do assume your "or" is used with the meaning of "alias" (you were talking about the same things, ergo hardware sequencer = microcode). Correct?

[brucehoult]

If properly designed (along with the hardware), millicode can provide essentially the same performance as hardware or microcode, but more cheaply in area and energy.

cheaply area is ok, I get it, but why cheaply energy?

Because in modern small processes leakage current is as significant (or more) than switching current, so area *is* energy use. Unless you can power gate it, but that's much slower than clock-gating and not practical to do for something that, for example, is used on every function entry and exit.

*faster* than a hardware sequencer or microcode.

the traditional meaning of microcode is that given an opcode, it's decoded into an index that points to the micro-ROM, *from* where micro-instructions are then sequenced.

I do assume your "or" is used with the meaning of "alias" (you were talking about the same things, ergo hardware sequencer = microcode). Correct?

No.

If maybe the only non-RISC thing you have in your ISA is, say, push/pull multiple for function entry and exit then you're probably not going to go to the trouble of making a general purpose microcode facility. You'll just have a little bit of hardware that increments the stack pointer while clearing bits from the register mask. That bit of hardware might do the actual loads/stores too, or it might inject a series of normal load and store instructions (maybe with auto-increment/decrement if you have that) into the pipeline while holding the push/pop multiple instruction in the decode stage.

I see that as very different to microcode.

[rrinker]

 The SCRT techniques for the 1802 were quite elegant, taking advantage of the simple method of calling a subroutine simply by changing which register was the PC. Something you can;t do in a CPU with a dedicated program counter register.  And easily understood, too.
 There's an active group still developing software and even new hardware using the 1802 - they've experimented with later versions as well and can get pretty decent clocks out of them, instead of the typical 1 or 2MHz used at the time. They often ran these systems slow because a standard NTSC colorburst crystal was used as the clock source, which enabled simple video using the 1854 video display chip. That resulted in a rather slow overall system though.

 C is available, as is FORTH.

 Another thing is the 1802 was available in a radiation hardened version, making it useful for space and military applications. The SAE receiver with the built in oscilloscope that Techmoan has done a video on uses an 1802 for the tuner preset control. Lots of scientific projects used the 1802 because of the ultra low power drain.

[brucehoult]

The SCRT techniques for the 1802 were quite elegant, taking advantage of the simple method of calling a subroutine simply by changing which register was the PC. Something you can;t do in a CPU with a dedicated program counter register.  And easily understood, too.

It's easily understood what it does, but perhaps not so easily understood how to make best use of it.

Very fast, too, at least compared to doing anything else on it :-) There's the minor annoyance of having to explicitly branch back to the start of the function so it's ready for next time. As we've seen, the convention was to put the "return" instruction at the start of the function, but that's not necessary. It could equally well go just before the branch back to the start. The only difference is whether you suffer the latency of the branch at the start of the function or the end.

You can do something very similar on CPUs that use link registers instead of putting return addresses on the stack.

For example on ARM you could keep the address of one of these "circular functions" in, say, r10, and then call it with BLX r10 and then the called function could do MOV r10, lr. The function return would use the same instructions. So, this is swapping the current PC with the address of the function, and then swapping it back later.

On RISC-V the link register is explicit, so you'd just do JALR r10, 0(r10) and the called function would return in the same way.

It *might* be worth using such techniques on ARM and RISC-V if you had a program with very limited depth (and non-recursive) of function call graph and you really really didn't want to write return addresses to RAM and read them back. I can't think why you'd want to do that unless you didn't actually have any RAM :-) Or if it was very very slow.

[macboy]

AFAIK the number of bits of a CPU is the width of the data bus.

(but referred to the data bus inside the CPU, because ... there are CPUs with 128-bit data bus and it's used to increase the bandwidth with the RAM, but clearly, data are 32 bit, thus transferred as 4 x 32bit words during  boost cycles

I wrote the CPU. Not the memory interface!

Every attempt to classify something will probably fail.  Why would anybody build a bit-serial ALU?  Beats me but it was done a long time ago when memory was an mercury magnetostrictive delay line 1 bit wide and 320(?) bits deep on some numerical control equipment I was working on.

Why would the Z80 use a 4 bit ALU when the predecessor 8080 used an 8 bit ALU?  Clearly this isn't a 4 bit processor (although I might claim it is!).

We can't use the datapath width and it isn't useful to use the address width.  For every metric that could be chosen, there will be an exception.

So, let's just use whatever the manufacturer chose and move on.

Classifying CPUs, especially early ones, isn't easy. I'll throw out a very difficult example: the Motorola 68000, ca. 1979.

It uses 32-bit data registers, a 32-bit program counter, and 32-bit address registers. The CPU can operate on 32-bit operands directly with single instructions, e.g. adding two 32-bit values in two registers. The instruction set is nominally 32 bit with a minimum instruction size of 16 bits and maximum of 80 bits (5 words).

Its address bus is 24 bits wide, so the CPU ignores the upper 8 bits. The external data bus is 16 bits wide. The ALU operates on up to 16 bit inputs, so operations on larger data types are implemented in microcode and take several cycles.

What do we call it? 32 bit due to exclusive use of 32-bit registers? 16 bit due to 16 bit native ALU size? That's a hard sell, because of so many counter-examples: Z80 with 4-bit ALU, the VexRiscv with 8-bit ALU (noted by ataradov), and many others. Do we call it 16 bit due to 16 bit external data bus? What about the smaller pin count but identical and binary compatible 68008 with its 8 bit external data bus? External data bus size isn't a good gauge. Many argue the 68000 CPU definitely has a 32 bit architecture, while others staunchly disagree and call it 16 bit. Maybe they don't want to believe that a successful 32 bit CPU was actually introduced to the mass market in 1979, because it isn't/wasn't their favorite.

[brucehoult]

Classifying CPUs, especially early ones, isn't easy. I'll throw out a very difficult example: the Motorola 68000, ca. 1979.

It uses 32-bit data registers, a 32-bit program counter, and 32-bit address registers. The CPU can operate on 32-bit operands directly with single instructions, e.g. adding two 32-bit values in two registers. The instruction set is nominally 32 bit with a minimum instruction size of 16 bits and maximum of 80 bits (5 words).

Its address bus is 24 bits wide, so the CPU ignores the upper 8 bits. The external data bus is 16 bits wide. The ALU operates on up to 16 bit inputs, so operations on larger data types are implemented in microcode and take several cycles.

What do we call it? 32 bit due to exclusive use of 32-bit registers? 16 bit due to 16 bit native ALU size? That's a hard sell, because of so many counter-examples: Z80 with 4-bit ALU, the VexRiscv with 8-bit ALU (noted by ataradov), and many others. Do we call it 16 bit due to 16 bit external data bus? What about the smaller pin count but identical and binary compatible 68008 with its 8 bit external data bus? External data bus size isn't a good gauge. Many argue the 68000 CPU definitely has a 32 bit architecture, while others staunchly disagree and call it 16 bit. Maybe they don't want to believe that a successful 32 bit CPU was actually introduced to the mass market in 1979, because it isn't/wasn't their favorite.

I think there are only two interesting questions:

1) what does software think it is?

2) what bus width does the PCB have to support?

The answer to the first is simple: it's a 32 bit instruction set. You can easily write programs that run on a 128 KB original Macintosh, but that can use 4 GB (or 2 GB anyway) of virtual memory on a later Mac with 68030 or 68040 processor.

For the second question: 24 bit address bus (16 MB), and 16 bit data bus.


The 68040 brought out a full 32 bits for both address bus and data bus. I don't know what the maximum physical memory was that anyone ever put onto a 68040. Apple supported 128 MB on all (?) 68030 and 68040 machines but I never knew anyone who wanted to spend the money for more than maybe 32 MB. Towards the end I think third party upgrades made 256 MB possible on maybe the Quadra 950. Maybe there were Sun or other Unix workstations that could take more. But the chip itself could address a full 4 GB externally.

*Everything* else affects the speed that programs run at, but not what they can do.

[helius]

The 68040 brought out a full 32 bits for both address bus and data bus.

I'm not entirely sure why you credit the 68040 here, since that was true ever since the 68020 in 1984.
Sun never used the 68040. I think its only use in workstations was by HP/Apollo.

[coppice]

The 68040 brought out a full 32 bits for both address bus and data bus.

I'm not entirely sure why you credit the 68040 here, since that was true ever since the 68020 in 1984.
Sun never used the 68040. I think its only use in workstations was by HP/Apollo.

Sun moved to SPARC well before the 68040 came out. Both Apple and NeXT used the 68040.

[brucehoult]

The 68040 brought out a full 32 bits for both address bus and data bus.

I'm not entirely sure why you credit the 68040 here, since that was true ever since the 68020 in 1984.

What do you mean by "credit"? I made a simple statement of fact about the 68040.

I neither stated nor implied anything about the 68020 or 68030, other than that Apple supported 128 MB RAM on 68030 machines, which implies that at least 27 address bits were brought out on the 68030 -- or 28 bits if the entire 128 MB was usable, as there was obviously address space for ROM and IO too.

[helius]

You can refer to the Microprocessor User's Manual from Motorola (M68040UM/AD) for actual information, instead of relying on incomplete inferences.
The 68040 has a 32-bit address bus, 32-bit data bus, as well as 20 various attribute and status signals, and ~20 bus control lines. It has 2 attribute bits that can be programmed through the MMU, so the total addressable memory is more like 16GB.

[brucehoult]

I referred to a 68040 package pin diagram, which showed d0..d31 and a0..a31. That seemed good enough for me.

If you want to play tricks with other signals go right ahead, but I bet no one ever got near to putting 4 GB RAM on a 68040 anyway -- at least not in the 90s. There would be very little point in doing so, even today, as the relationship of 1 MB RAM for each 1 MIPS of processing power on a general purpose computer has held constant to within a small factor (typically < 2, but certainly < 10) for the last half century. Fairly often people build machines with less RAM than implied by this rule, but it would be very rare to build one with more -- maybe some kind of specialised database server.

[westfw]

Classifying CPUs, especially early ones, isn't easy. I'll throw out a very difficult example: the Motorola 68000, ca. 1979.

Yes.

The 68040 brought out a full 32 bits for both address bus and data bus.

Also yes.  It was only the 68000 and 68010 that were "difficult" (ok, 68008, 68302, and maybe a couple more as well) - by the time Motorola got to the 68020, they were calling it "the 32-bit performance standard", the embedded version was called "CPU32", and no one had any complaints about them calling them 32bit chips.

I theoretically have the parts to put together a Mac-IIci (68030) with 128Mbyte of memory (8x 16MB simms), and it almost seemed like a neat idea when I first acquired the 16MB simms.  But only almost; that sort of "unbalanced" system just isn't very useful.
[back to another topic]

In RISC-V land we call these kind of special helper routines "millicode".

I like that phrase.  The PDP-10 had "UUOs" - Unimplemented User Opcodes, or some such.  Basically, a bunch of undefined opcodes in the instruction set that would instead trap to system code (OS System Calls used them for Tops-10) or user code.  Since the PDP-10 also had a "standard effective address calculation" that calculated the final address of the memory operand (including indexing and indirection), even for the UUOs, you got instructions that were partly implemented by the hardware in microcode, and partly by user-provided "normal" code.  They were pretty neat.  Most CPUs that trap unimplemented opcodes can do something similar, but they don't have the memory addressing done for you...  (I guess they must have been pretty slow, though, since the next OS (Tops20) went to a more conventional "load up registers and use the "systemcall" instruction" mechanism.)