Author Topic: Microcontrollers memory  (Read 15122 times)

0 Members and 1 Guest are viewing this topic.

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Microcontrollers memory
« on: December 27, 2018, 01:27:33 pm »
When a microcontroller executes a program, does it read it from ROM, or does it copy to RAM when it turns on and then execute it reading from RAM?

Thank you.
 

Offline martinayotte

  • Regular Contributor
  • *
  • Posts: 64
Re: Microcontrollers memory
« Reply #1 on: December 27, 2018, 01:59:46 pm »
Most microcontrollers are executing directly from code. But it all depends about which microcontroller you are talking, because some others such ESP8266 or ESP32 are fetching ROM code into RAM cache before executing it.
 
The following users thanked this post: nForce

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Microcontrollers memory
« Reply #2 on: December 27, 2018, 02:32:05 pm »
it also depends on architectural's choices. Since having the fetch unit on the same bus of the load/store unit is considered a "structural hazard" for a RISC-pipelined architecture, modern CPUs usually fetch the code from a dedicated bus.

This is called "Harvard Architecture", defined as a computer architecture with physically separate storage and signal pathways for instructions and data, which implies the opcode in ROM is on a different space from the data in RAM. This simplifies the pipeline and makes thing faster, but as a downside, these CPUs then need a "bridge" (a piece of dedicated hardware) to make it possible to read and copy the code from the ROM to the RAM.

Without the "bridge" (or a similar hardware trick) it's physically impossible, and you end by fetching your code from the ROM and that's all you can do.
« Last Edit: December 27, 2018, 10:53:33 pm by legacy »
 
The following users thanked this post: nForce

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 14076
  • Country: de
Re: Microcontrollers memory
« Reply #3 on: December 27, 2018, 04:10:36 pm »
It depends on the µC: especially the smaller ones usually run the code directly from ROM (flash). Faster ones might be faster running from RAM.  For the modern ARM based µC one often has the choice, depending on the speed needed.  Flash rom is somewhat limited in access speed, while SRAM is more expensive.  Sometimes there is some in between cache to speed up ROM access.
 
The following users thanked this post: nForce

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: Microcontrollers memory
« Reply #4 on: December 27, 2018, 04:14:46 pm »
To give a more practical answer:

Harvard-type CPU architectures (many micros, like PIC and AVR) have a separate program and data bus. The CPU fetches instruction from ROM, with the program image starting at address zero. The data memory space typically has hardware registers at address 0, and RAM starting at some other value.
Example: PIC24, it has the RAM starting at 0x800 and SFR at 0x0 to 0x7FF. If the firmware wants to load values from ROM, it can use special table read/write instructions to do so. I think on AVR you had to specifically mark/retrieve variables as PGM.
These CPUs don't have the capability of running code from SRAM.

ARM on the other hand, is a von Neumann machine. This means that the code, hardware registers and RAM reside in 1 single memory space. This is needed for the option to execute code from RAM.
One reason why you might do that, is because some FLASH is not that quick, and FLASH accelerators are used to hide that limitation by 'caching' wide lines of the FLASH memory (e.g. read 1024-bits at once, then execute opcodes of 16 or 32 bits). Sometimes execution from RAM consumes less power. Execution from RAM can also be more predictable w.r.t. timing.
Or perhaps you want to run Linux or some other large firmware image, which you could run from an external S(D)RAM chip.

Many microcontrollers stick to the principle the simpler the better, and will probably execute their program directly from FLASH. The previously mentoined scenarios are reason to change, but are a PITA to implement & debug completely from scratch and best to be avoided if you can.
 
The following users thanked this post: nForce

Offline boB

  • Frequent Contributor
  • **
  • Posts: 307
  • Country: us
    • my work www
Re: Microcontrollers memory
« Reply #5 on: December 27, 2018, 04:26:18 pm »
To give a more practical answer:

Harvard-type CPU architectures (many micros, like PIC and AVR) have a separate program and data bus.

Wasn't the old intel 8080 and Z80 also Harvard ?

I've used the X86 a lot in the past but today can't remember which it is ?

I suppose that after an instruction is fetched from ROM/Flash/RAM and moved into the decoder and into the ALU, it's then a RAM type register or read only at that point from the user's aspect because only the processor  can see the info at that time (usually) depending on how deep you want to talk about this question's answer :)

K7IQ
 

Offline tsman

  • Frequent Contributor
  • **
  • Posts: 599
  • Country: gb
Re: Microcontrollers memory
« Reply #6 on: December 27, 2018, 04:36:17 pm »
It depends on the uC you're using.

does it copy to RAM when it turns on and then execute it reading from RAM?
The GigaDevices GD32 clones of the STM32 chips do that. They attached a flash die to the uC die inside the package which is read into an additional block of RAM at startup.
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Microcontrollers memory
« Reply #7 on: December 27, 2018, 05:06:30 pm »

Wasn't the old intel 8080 and Z80 also Harvard ?

No, data and instructions are in the same memory space so they are von Neumann architecture.
Quote

I've used the X86 a lot in the past but today can't remember which it is ?

Still von Neumann...
[/quote]

When ARM produced the earlier ARM7TDMI chips (LPC2106, LPC2148, etc), they decided to execute code out of Flash.  What to do about the slow fetch?  How about an old IBM trick and grab a lot more than 32 bits?  In fact, these chips grab 128 bits at a time from Flash.

2d sentence page 3 here:

http://www.keil.com/dd/docs/datashts/philips/user_manual_lpc214x.pdf

There is some memory mapping required for the vectors.  Section 2.2.1 describes the memory mapping.

I haven't really followed the ARM Cortex chips so I have no idea how they deal with code and flash.
« Last Edit: December 27, 2018, 05:08:13 pm by rstofer »
 
The following users thanked this post: nForce

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #8 on: December 27, 2018, 06:40:38 pm »
What about variables? So if 8-bit PIC or AVR uses Flash ROM for reading, where are stored variables? Because we should use some of RAM if it's there.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Microcontrollers memory
« Reply #9 on: December 27, 2018, 07:04:40 pm »
The distinction between architecture types get weaker as you get more complex CPUs with seperate instruction and data caches, and multiple levels of cache too.

Perhaps a practical definition (from a programmers point of view) is if the are seperate code and data address spaces. Most general purpose CPUs have just one address space, but in microcontroller it is very common to seperate code and program address spaces 

Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: nForce

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Microcontrollers memory
« Reply #10 on: December 27, 2018, 10:08:59 pm »
What about variables? So if 8-bit PIC or AVR uses Flash ROM for reading, where are stored variables? Because we should use some of RAM if it's there.

Of course the variables have to be in RAM as do all the control registers and anything else that can be written.  These are on an entirely separate address and data bus for chips like the PIC and the ARM7TDMI (and probably all other ARM chips).  But it is architecture dependent whether there are separate memory domains.  Clearly the Z80 has just one address and data bus but the designer can put Flash anywhere in the address space.  That doesn't suddenly change a von Neumann architecture into a Harvard architecture.  If there is only one memory domain, it's von Neumann.  If there are two memory domains (one for program, one for data) then it is Harvard.

The idea was to deconflict instruction fetch from memory from core read/write memory.  Having two separate domains allows both operations to occur simultaneously.

 
The following users thanked this post: nForce

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #11 on: December 28, 2018, 12:51:05 pm »
What about the word "8-bit" MCU.  In the old days, there were MCU which had 8-bit instruction word and 8-bit memory word and 8-bit data bus. But today there are some MCU which have maybe 16-bit memory word, or something else but the data bus is still 8-bit. Can we say that this MCU isn't 8-bit anymore?
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Microcontrollers memory
« Reply #12 on: December 28, 2018, 01:04:51 pm »
Example: PIC24, it has the RAM starting at 0x800 and SFR at 0x0 to 0x7FF. If the firmware wants to load values from ROM, it can use special table read/write instructions to do so.

Actually, 16 bit pics (PIC24 and dSPIC) can map the flash in the upper 32kB of data memory, so it can be accessed as if it was some read-only data memory, but with every addressing mode available and also by the dsp engine.
There are hree caveats though:
- It takes more than one clock cycle, as it is accessing flash
- The flash is mapped in 32kB pages, if your constant map happens to cross the boundary or you have to change the value of the PSVPAG register. Also, you have to explicitely enable arrays of more than 32kB in the compiler for this reason (a check on PSVPAG is done only when required and not before every access, which would slow things down a lot)
- You actually access the lower 16bit, the instruction is 24bit wide, the flash cell is 48bit wide containing two 24 bit instructions. If you need to access the whole word you need to use table read instructions (which still have many addressing modes)

Special mention: in the dsPIC33CH the second core (slave core) is held waiting at reset, you need to excecute a special instruction to load the program memory image for the slave core in SLAVE PRAM (program ram). The master at any moment can halt the slave and load a different image so the slave is effectively running from ram and can run different firmwares.. with much less latency because it's running from RAM. Cool, aye :)?
 
The following users thanked this post: hans

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Microcontrollers memory
« Reply #13 on: December 28, 2018, 06:01:06 pm »
ARM on the other hand, is a von Neumann machine. This means that the code, hardware registers and RAM reside in 1 single memory space. This is needed for the option to execute code from RAM.
No. This isn't right. ARM is a modified Harvard processor. This means the instruction and data busses are seperate but externally connected to form a single memory space. This means no extra instruction are needed to transfer between various types of memory. This also scales much better when using the C language. On a Harvard CPU with seperated memory spaces you can't use pointers in C (without a major speed penalty or severe limitations). Besides that modern ARM based microcontrollers usually allow to have concurrent flash, DMA and SRAM accesses. As usual the lines have become blurred.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: hans

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Microcontrollers memory
« Reply #14 on: December 28, 2018, 06:03:42 pm »
What about the word "8-bit" MCU.  In the old days, there were MCU which had 8-bit instruction word and 8-bit memory word and 8-bit data bus. But today there are some MCU which have maybe 16-bit memory word, or something else but the data bus is still 8-bit. Can we say that this MCU isn't 8-bit anymore?

The concept of "8-bit" or "16-bit", etc, is usually the width of the arithmetic logic unit (ALU).  The 8085, for example, had a 16 bit address but there were only 8 address lines coming out of the chip.  The high 8 address bits were sent out on the address pins and the low 8 bits were sent out on the bidirectional A/D (address/data) bus where they were latched so that the data could be sent over the A/D bus in the next cycle.

See about 3/4 the way down this page for a block diagram:

https://www.quora.com/What-is-function-of-ALE-in-8085

At the time, a 40 pin chip was thought to have a LOT of pins for a DIP package and there weren't many packages larger than this.  The Motorola 68000 used a 64 pin DIP.
 
The following users thanked this post: nForce

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #15 on: December 28, 2018, 06:37:21 pm »
Quote
The concept of "8-bit" or "16-bit", etc, is usually the width of the arithmetic logic unit (ALU).

You mean the accumulator, which stores an operand for ALU?
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Microcontrollers memory
« Reply #16 on: December 28, 2018, 06:52:19 pm »
What about the word "8-bit" MCU.

there was a fun thread about this not many months ago :D
was it this one? https://www.eevblog.com/forum/microcontrollers/8-bit-uc-is-there-even-a-point/
i remember at some point it degenerated in a phylosophical discussion on how to determine the true kind of a mcu
 

Offline boB

  • Frequent Contributor
  • **
  • Posts: 307
  • Country: us
    • my work www
Re: Microcontrollers memory
« Reply #17 on: December 28, 2018, 09:23:27 pm »

Then what was the Harvard architecture processor I used to use ?

I bet it was a DSP then cuz they have a rather unique way about them.  DSP56001  or maybe I'm thinking of the intel 8031 family ?

Can't remember now.  Too old.
K7IQ
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Microcontrollers memory
« Reply #18 on: December 28, 2018, 09:37:38 pm »
You mean the accumulator, which stores an operand for ALU?
For older architectures with a single accumulator, sure. But there are no modern architectures that use accumulator. It just does not make sense and compilers can't deal with accumulators well.

ALU itself has a certain number of bits regardless of where the operands come from. And the with of the operands is probably the best definition for bitness of the MCU.
« Last Edit: December 28, 2018, 09:39:32 pm by ataradov »
Alex
 
The following users thanked this post: nForce

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Microcontrollers memory
« Reply #19 on: December 29, 2018, 12:42:31 am »
I bet it was a DSP then cuz they have a rather unique way about them.  DSP56001  or maybe I'm thinking of the intel 8031 family ?


(my first board, designed and handmade in 1994. It was loaded with Intel basic 51)


(the board was designed by following this book, printed by Intel and offered)



Intel 8051 is Harvard in the meaning it uses a special signal "/psen" for acknowledging the code-area, but data and addresses are shared between the code space and the data space.

See the pic, you can see the memory mapped I drawn years and years ago. Note the two spaces are separated even if addresses numerically collide (except for the trick for the three NVRam Chips that are mapped in both Code space and Ram space thanks to the Intel's trick described in the book).

This is clearly not a "structural hazard", it's simply a way to distinguish the data from the code, and there are tricks (reported by Intel in the above book) for being able to read and write into the code space so a bootloader can be written in a way it can reprogram its own flash. Otherwise ... you cannot on-board reprogram an 8051's flash and you end by programming the chip manually with an external tool (e.g. ROM-emulator, or prom programmer).

The DSP56001 is a "modified Harvard architecture" processor with three memory spaces and on-chip memory banks in some of the models. It allows the contents of the instruction memory to be accessed as if it were data and it's a weird beast with the uncommon data size of 24 bit.

A pure RISC-Harvard machine expresses the need to have the code space and the data space in a way the CPU can fetches opcodes and simultaneously accesses the Ram. In this case, the purpose of being "Harvard" is clearly an attempt to solve the "structural hazard" in a way that fetches and IOs can be performed simultaneously.

This is a need for the pipeline and modern pipelined-RISC-ish CPUs and MPUs are all "modified Harvard architectures" or "pure Harvard architectures with *the bridge*"  :D
« Last Edit: December 29, 2018, 01:13:17 am by legacy »
 

Offline boB

  • Frequent Contributor
  • **
  • Posts: 307
  • Country: us
    • my work www
Re: Microcontrollers memory
« Reply #20 on: December 29, 2018, 02:03:53 am »

A pure RISC-Harvard machine expresses the need to have the code space and the data space in a way the CPU can fetches opcodes and simultaneously accesses the Ram. In this case, the purpose of being "Harvard" is clearly an attempt to solve the "structural hazard" in a way that fetches and IOs can be performed simultaneously.

This is a need for the pipeline and modern pipelined-RISC-ish CPUs and MPUs are all "modified Harvard architectures" or "pure Harvard architectures with *the bridge*"  :D

Yes !  A very good advantage for Harvard being able to access the opcode flash AND the RAM at the same time.

Kind of like (but not really) dual port RAM.  Remember that ?  Back when I was playing with CRT display processors, I could have used that.
I bet that feature exists in todays' graphics processors but you (or I anyway) cannot have access to that documentation unless we spend
billions of dollars.

And I certainly remember the DSP56001's  X and Y memory.


K7IQ
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Microcontrollers memory
« Reply #21 on: December 29, 2018, 02:06:33 am »
Kind of like (but not really) dual port RAM.  Remember that ?  Back when I was playing with CRT display processors, I could have used that.
I bet that feature exists in todays' graphics processors but you (or I anyway) cannot have access to that documentation unless we spend
billions of dollars.
There is dual port RAM in most FPGAs.
Alex
 

Offline boB

  • Frequent Contributor
  • **
  • Posts: 307
  • Country: us
    • my work www
Re: Microcontrollers memory
« Reply #22 on: December 29, 2018, 02:16:49 am »
Kind of like (but not really) dual port RAM.  Remember that ?  Back when I was playing with CRT display processors, I could have used that.
I bet that feature exists in todays' graphics processors but you (or I anyway) cannot have access to that documentation unless we spend
billions of dollars.
There is dual port RAM in most FPGAs.

Really ?  I didn't know that.  But I don't use many FPGAs.  Except for the cheapest versions (Silego) they're just too expensive for what I need (several dollars each)

Do these dual port RAMs have lock-outs or contention management for when two pieces of logic try to write to the same location ?  Maybe that is not as important as when one location is being written while it is also being read.  Or maybe it just doesn't matter.
K7IQ
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Microcontrollers memory
« Reply #23 on: December 29, 2018, 02:20:50 am »
Do these dual port RAMs have lock-outs or contention management for when two pieces of logic try to write to the same location ?  Maybe that is not as important as when one location is being written while it is also being read.  Or maybe it just doesn't matter.
It matters and they do either configurable or predictably behaved contention management. Plus you get configurable bypass of the new data to the read ports.

BRAMs are fundamental to even medium-scale FPGAs. Without BRAM most of them will have very limited utility.
Alex
 
The following users thanked this post: boB

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Microcontrollers memory
« Reply #24 on: December 29, 2018, 02:29:27 am »
Quote
The concept of "8-bit" or "16-bit", etc, is usually the width of the arithmetic logic unit (ALU).

You mean the accumulator, which stores an operand for ALU?

Maybe...

I prefer to think of the ALU width because there could very well be an overwide accumulator.  I won't go into details but the 16 bit IBM 1130 had a 16 bit accumulator with a 16 bit extension.  True, the extension wasn't called the accumulator but it was coupled to the ALU and used for multiply and divide as well as some shifts.

8080 style CPUs have at least 4 double wide registers SP, BC, DE, HL for holding 16 bit values.  Sure, each register of the pair is only 8 bits but the DAD (double add) did a 16 bit addition in 8 bit chunks as in DAD BC which added BC to HL and left the result in HL.  I'm pretty sure the chip used the same 8 bit ALU.
 
The following users thanked this post: nForce

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #25 on: December 29, 2018, 02:55:06 am »
Quote
The concept of "8-bit" or "16-bit", etc, is usually the width of the arithmetic logic unit (ALU).

You mean the accumulator, which stores an operand for ALU?

Maybe...

I prefer to think of the ALU width because there could very well be an overwide accumulator.  I won't go into details but the 16 bit IBM 1130 had a 16 bit accumulator with a 16 bit extension.  True, the extension wasn't called the accumulator but it was coupled to the ALU and used for multiply and divide as well as some shifts.

8080 style CPUs have at least 4 double wide registers SP, BC, DE, HL for holding 16 bit values.  Sure, each register of the pair is only 8 bits but the DAD (double add) did a 16 bit addition in 8 bit chunks as in DAD BC which added BC to HL and left the result in HL.  I'm pretty sure the chip used the same 8 bit ALU.

ALU width doesn't seem like a very good measure to me.

Maybe the 8080 had an 8 bit ALU but I know for a fact the Z80 had a 4 bit ALU. Are you going to call the Z80 a 4 bit processor? That would be strange, as the Z80 runs all 8080 programs.

In the recent RISC-V SoftCPU Contest the 1st place winner VexRiscv uses an 8 bit ALU. The Creativity Prize winner, SERV, uses a bit-serial (i.e. 1 bit) ALU. So, apparently you'd call them an 8 bit processor and a 1 bit processor.

But they both implement exactly the same RV32I instruction set! They run the same programs.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Microcontrollers memory
« Reply #26 on: December 29, 2018, 11:41:21 am »
AFAIK the number of bits of a CPU is the width of the data bus.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #27 on: December 29, 2018, 12:42:19 pm »
Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Microcontrollers memory
« Reply #28 on: December 29, 2018, 12:51:32 pm »
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

yesterday, at the 452123213768240909232433439-th attempt, I understood I'd better avoid asking my colleagues about the energy of the empty space since the only true thing is that quantum mechanics is easier to be clarified as "you'd better don't question(1)"

The same applies to attempts of trying to classify a CPU ...


(1) the question was: WTF is the energy of an empty box containing dark and empty space at -272C?
I would say "zero": if there is neither light (electromagnetic things) nor matter then there is no energy. Easy like a cake! But no & NO! *they said* that it contains a lot of fluctuating pairs of quantum particles thus it has *A LOT* of energy X___X ... and it can also degrade to an not empty universe, where "not empty" is in the meaning of pure energy particles that can get a mass thanks to Higgs field which has no problem at working at -272C (WTF!?!?!? oh, well .. at this point my brain was going to evaporate)


in short: * What * The * Frog *?!?! What does make a 32bit CPU a "32bit" thing?
don't question! unless you are not really afraid of the answers  ;D)
« Last Edit: December 29, 2018, 01:06:58 pm by legacy »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Microcontrollers memory
« Reply #29 on: December 29, 2018, 02:08:01 pm »
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!
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Microcontrollers memory
« Reply #30 on: December 29, 2018, 02:58:09 pm »
I wrote the CPU. Not the memory interface!

you wrote "data bus". Technically even the memory interface is a "data bus" :D
mine was an attempt to make a nice and funny point(1), nothing serious.

(1) specifically, I was laughing about a comment made by guys on a 68080 prototype made around a large FPGA with a 128bit interface to the DRAM ... it happened that someone really asked if it was a new member of the 68k family at 128 bit ...  thanks God he was not a blog-writer :-DD :-DD :-DD
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Microcontrollers memory
« Reply #31 on: December 29, 2018, 03:17:00 pm »
It is often better to avoid classifying things. Classification is only useful when the results of the classification are needed for other things.
 
The following users thanked this post: rs20

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Microcontrollers memory
« Reply #32 on: December 29, 2018, 09:44:11 pm »
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.
 

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #33 on: December 29, 2018, 09:49:57 pm »
Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Microcontrollers memory
« Reply #34 on: December 29, 2018, 09:51:51 pm »
Why would anybody build a bit-serial ALU?
But even with split ALUs, they still perform an atomic operation on some number of bits.

That VexRiscv with 8-bit ALU, still does only 32-bit computations. It just takes multiple cycles to complete. That ALU as an actual unit takes 32-bit numbers and provides 32-bit outputs. It does not matter how it is done inside.

So that classification holds.

Although I do agree, classifications are arbitrary for a task and useless in abstract.
Alex
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: Microcontrollers memory
« Reply #35 on: December 29, 2018, 11:26:25 pm »
Why would anybody build a bit-serial ALU?
Bit serial is very gate efficient for low to medium speed requirements. As the speed requirement goes up you either need to move to serial by parallel or full parallel architectures, or have a lot of bit serial hardware working in parallel. When gates were expensive things like entry level PDP8s were available in bit serial form. A number of massively parallel machines (MPP, ASPRO. etc) were built with thousands of bit serial ALUs working in parallel. These had a very low chip count for the throughput they could achieve. However, as geometries became finer things like propagation delays, and clock tree structures began to make these massively parallel structures fail badly. In the late 70s I used to implement DSP solutions with a mix of parallel, serial by parallel and bit serial hardware in the same design, handling aspects of the problem with different throughput requirements. A lot of modest speed DSP in ASICs is still implemented with bit serial arithmetic (e.g. in CD player chips).
 

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #36 on: December 30, 2018, 03:20:37 pm »
I will be happy if someone answers my question.  :)
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #37 on: December 30, 2018, 03:47:04 pm »
I will be happy if someone answers my question.  :)

Which question? The original one? Many people have answered it. The answer is "It depends". Unless you can tell exactly *which* microcontroller you are talking about.
 

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #38 on: December 30, 2018, 04:28:52 pm »
I will be happy if someone answers my question.  :)

Which question? The original one? Many people have answered it. The answer is "It depends". Unless you can tell exactly *which* microcontroller you are talking about.

No, the other one, here:

Quote
Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?

 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Microcontrollers memory
« Reply #39 on: December 30, 2018, 05:25:51 pm »
I will be happy if someone answers my question.  :)

Which question? The original one? Many people have answered it. The answer is "It depends". Unless you can tell exactly *which* microcontroller you are talking about.

No, the other one, here:

Quote
Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?

As pointed out above, the Z80 uses a 4 bit ALU with 8 bit registers so even ALU width is meaningless as a descriptor.  I never realized the ALU was only 4 bits but, sure enough, it is.
 
The following users thanked this post: nForce

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #40 on: December 30, 2018, 05:42:55 pm »
Oh, thanks rstofer.

But what is then ALU width, if the registers width is different?

And another question what is the width of the memory word in a modern computer? Is it 64 bits? Or is it still 8 bits, and the CPU when fetching (fetch cycle) reads 8 words?
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Microcontrollers memory
« Reply #41 on: December 30, 2018, 06:51:37 pm »
But what is then ALU width, if the registers width is different?

There are wires coming into ALU. Some of these wires are supplying operands. The number of wires supplying a single operand would be the width of the ALU.

And another question what is the width of the memory word in a modern computer? Is it 64 bits? Or is it still 8 bits, and the CPU when fetching (fetch cycle) reads 8 words?

Modern PCs use DDR4 memory. Each data wire of the memory chip supplies/accepts data in bursts of 8 bits at a time. DIMM has 64 data wires, which means a memory transaction deals with 8x64 = 512 bits. This is demultiplexed as needed to fit a cache line, which is, coincidently, 64 bytes - the same as DDR4 burst from DIMM. There are multiple levels of cache, which are then interconnected in a fancy way to multiple cores.  The core can fetch as much as it needs. Since some of the registers are 512-bit now, it should be able to fetch the entire 512-bit cache line at a time.

It is all changing at a fast pace. What I write might be already obsolete :)
 
The following users thanked this post: nForce

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Microcontrollers memory
« Reply #42 on: December 30, 2018, 07:38:56 pm »
Oh, thanks rstofer.

But what is then ALU width, if the registers width is different?
I would expect modern chips to have an ALU width that is more in line with the nomenclature for the chip.  Most ARMs would have a 32 bit ALU and 32 bit registers.  A modern x64 would have a 64 bit ALU and 64 bit registers but the architecture supports 32 bit subregisters.

To really discuss things like ALU width and memory width, we need to talk about a specific architecture because there are all kinds of variations.

Even IBM, back in the 360 mainframe days differentiated the models by memory path width.  The low end machine had an 8 bit data path and I believe the high end machine had a 64 bit data path. 
Quote
And another question what is the width of the memory word in a modern computer? Is it 64 bits? Or is it still 8 bits, and the CPU when fetching (fetch cycle) reads 8 words?

The word length doesn't change, just the number of words read per operation.  If gets complicated due to cache lines and multiword fetch.  See response above re: cache lines.
 
The following users thanked this post: nForce

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Microcontrollers memory
« Reply #43 on: December 30, 2018, 08:20:23 pm »
Quote
There are wires coming into ALU. Some of these wires are supplying operands. The number of wires supplying a single operand would be the width of the ALU.
I'm not sure that that explains the z80, unless you are real careful about defining where the edges of the ALU are.
Normally, the ALU is a section of  purely combinatorial logic that has a couple of inputs, and output, and some gates that select what operation should be preformed on the inputs to get the outputs.  To add two numbers, you need a "full adder" circuit (which is about 6 gates) for each bit of the number, and maybe a fast carry lookahead circuit.  The number of full adders implemented would be the "true" width of the ALU.

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #44 on: December 30, 2018, 08:35:02 pm »
I will be happy if someone answers my question.  :)

Which question? The original one? Many people have answered it. The answer is "It depends". Unless you can tell exactly *which* microcontroller you are talking about.

No, the other one, here:

Quote
Sorry, but I don't understand what does it mean ALU width?

Because ALU operates with operands which are stored in registers. (For older architectures accumulator). So register width would be the width of ALU?

As pointed out above, the Z80 uses a 4 bit ALU with 8 bit registers so even ALU width is meaningless as a descriptor.  I never realized the ALU was only 4 bits but, sure enough, it is.

I don't think any of those hardware-based statistics is the proper measure of 8-bit, 16-bit, 32-bit, 64-bit. They are all just implementation details that could change on a newer compatible processor with a different architecture but that runs all the same programs.

Ok, that basically never happened with microcomputers in the 1970s. Every new processor ran a completely different instruction set. At most -- and even in the 1980s -- at most a new microprocessor could run (most) programs from an older one, but not vice versa.

That wasn't the case with mini-computers and mainframes, even then.

In the 1960s IBM made dozens of different machines that all ran every program for the 32 bit IBM 360 instruction set. Some of them had 8 bit memory busses and some had 64 bit. Some executed most instructions in one clock cycle, and some used a little interpreter program (microcode) that took five or maybe even ten clock cycles to execute even simple instructions.

DEC made a wide range of CPUs that all could run the same PDP-11 programs -- and then a wide range of CPUs that all could run the same VAX programs. Data General and PR1ME did the same. Newer CPUs weren't necessarily faster than older ones -- they also pushed the compatible range down to smaller and cheaper (but slow) machines as time went on.

I think the only meaningful measure is something like "What is the largest data size that a program can use in a single instruction?" (you obviously need to not count things like the x86 "rep" prefix) The bit-ness is a property of the instruction set (and the programs), not of a particular micro-architecture implementing that instruction set.

That can be hard to understand for old instruction sets that only had a single implementation and then were abandoned.

And, yes, I think that means some old CPUs should be reclassified now, and in particular many of the "8 bit" CPUs should be reclassified as 16 bit -- pretty *poor* 16 bit CPUs, but 16 bit nonetheless.

For example the Z80 had single instructions to take the 16 bit contents of HL or IX or IY, add the contents of BC, DE, SP or itself, and put the result back in the original register. You could also add or subtract with carry any of BC, DE, HL or SP to HL, and as these set the flags according to the 16 bit result you could then branch directly according to that. You could directly load a 16 bit constant into any of BC, DE, HL, IX, IY, or SP or load or store a 16 bit value directly to/from any of those to an absolute memory location. You could also add an 8 bit constant to the contents of IX or IY and use the 16 bit result as a memory address to load or store any 8 bit register (A, B, C, D, E, H, L). You could push BC, DE, HL, IX or IY onto the stack, or pop them from the stack.

The only things you couldn't do directly with 16 bit values were to copy from one 16 bit register to another (but something like PUSH DE; POP BC is just two bytes of program code) or to load or store them via a pointer (which also needs two instructions).

The Z80 has a 16 bit instruction set. A pretty inconvenient one, in many ways, but the 8 bit instructions aren't exactly convenient to use either!
 
The following users thanked this post: nForce

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #45 on: December 30, 2018, 08:40:03 pm »
Quote
There are wires coming into ALU. Some of these wires are supplying operands. The number of wires supplying a single operand would be the width of the ALU.
I'm not sure that that explains the z80, unless you are real careful about defining where the edges of the ALU are.
Normally, the ALU is a section of  purely combinatorial logic that has a couple of inputs, and output, and some gates that select what operation should be preformed on the inputs to get the outputs.  To add two numbers, you need a "full adder" circuit (which is about 6 gates) for each bit of the number, and maybe a fast carry lookahead circuit.  The number of full adders implemented would be the "true" width of the ALU.

The Z80 has four full adders.

To add something wider than that it needs to store each 4 bit result into output latches and then go back and read a new set of 4 bit operands from input latches.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Microcontrollers memory
« Reply #46 on: December 30, 2018, 08:48:40 pm »
... and let us not get started on all the weird and exotic memory addressing models that differentiated 16-bit and 32-bit Operating System environments (esp in x86 land).
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Microcontrollers memory
« Reply #47 on: December 30, 2018, 09:44:04 pm »
Quote
The Z80 has four full adders.
To add something wider than that it needs to store each 4 bit result into output latches
Sure, that's fine.  But if you define "the ALU" a bit wider (ie including the output latches, and the circuitry that routes the half-bytes), then you have a "box" that has two 8-bit inputs and a latched 8bit output. Might as well call the whole thing "ALU" - it's not like there were any instructions to do 4bit operations...
(OTOH, I said that the ALU should be merely combinatronic, which would nix that definition.)

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #48 on: December 30, 2018, 09:50:33 pm »
Quote
The Z80 has four full adders.
To add something wider than that it needs to store each 4 bit result into output latches
Sure, that's fine.  But if you define "the ALU" a bit wider (ie including the output latches, and the circuitry that routes the half-bytes), then you have a "box" that has two 8-bit inputs and a latched 8bit output. Might as well call the whole thing "ALU" - it's not like there were any instructions to do 4bit operations...
(OTOH, I said that the ALU should be merely combinatronic, which would nix that definition.)

Not just 8 bit. The Z80 instruction set has instructions to add or subtract two 16 bit values.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Microcontrollers memory
« Reply #49 on: December 31, 2018, 01:19:41 am »
Quote
instructions to add or subtract two 16 bit values.
Is there a particular name for architectures that let you combine their native-sized registers into larger operands (or conversely: lets you use partial registers as separate smaller registers)?  (Examples being: well, many of the "8bit" CPUs have at least some 16bit instructions, and the 8086 had its whole AL, AH, AX thing.)I've always been a little annoyed that using byte operands on ARM (for example) "wastes" 75% of the register...
 

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #50 on: December 31, 2018, 08:55:59 pm »
Thanks :)

What about the length of a program counter? If it's 64 bits, then it can address 2^64 addresses. Can we say that this a 64-bit architecture, or if it's 32-bit length can the ALU length be 64 bit?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Microcontrollers memory
« Reply #51 on: December 31, 2018, 08:58:28 pm »
What about the length of a program counter?
It is absolutely irrelevant to anything. It is not a useful measure or parameter.

Again, classifications on their own are useless. You introduce classifications to serve your needs for a specific task. The same MCUs may be classified differently for different purposes.
Alex
 
The following users thanked this post: nForce

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #52 on: December 31, 2018, 09:22:59 pm »
What about the length of a program counter?
It is absolutely irrelevant to anything. It is not a useful measure or parameter.

Again, classifications on their own are useless. You introduce classifications to serve your needs for a specific task. The same MCUs may be classified differently for different purposes.

Why then the 64-bit processor can address 2^64 addresses?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Microcontrollers memory
« Reply #53 on: December 31, 2018, 09:25:22 pm »
Why then the 64-bit processor can address 2^64 addresses?
They typically can't. 64-bit X86 processors can typically address 48-bits.

But even if they could, the question still does not make much sense. The answer would be - because someone designed it this way.

Also, 64-bit processors typically have MMU, so discussing addressing ranges becomes a tricky task and a subject to more arbitrary classifications.
« Last Edit: December 31, 2018, 09:30:31 pm by ataradov »
Alex
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #54 on: December 31, 2018, 11:23:37 pm »
Why then the 64-bit processor can address 2^64 addresses?
They typically can't. 64-bit X86 processors can typically address 48-bits.

You're confusing architecture and implementation.

x86_64 processors built *today* have 48 physical address pins.

Future ones might have 50 or 56 or 60 or 64 .. and today's software will run on them unchanged (not even recompiled), and automatically take advantage of the extra memory.

Chips come and go every year or two. Software is forever.

The only thing that kills software is when affordable hardware gets bigger than old software can use, and then you have to make a new incompatible instruction set and throw away or rewrite the old software.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Microcontrollers memory
« Reply #55 on: December 31, 2018, 11:26:50 pm »
You're confusing architecture and implementation.
Not really. I'm just providing the information on currently existing devices.

And previously 32-bit processors could address more thought PAE.  You can obviously make whatever CPUs you like. That just furthers the point that abstract classifications are mostly useless.

And whether current software will run unchanged is a big question. There are many more things that will affect this other than architecture of the CPU.
Alex
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #56 on: January 01, 2019, 12:09:34 am »
You're confusing architecture and implementation.
Not really. I'm just providing the information on currently existing devices.

That's not really a useful thing to do.

If there was a customer today who could afford to populate a computer with 2^64 bytes of physical RAM then Intel would bring out a chip with 64 bits of physical address just as quickly as they could turn around some wafers from the fab. And so would SiFive.

There is *zero* technical challenge in bringing out 64 bits instead of 48.

It would take me all of five minutes to go and change the relevant parameter in the Chisel source code and I'd have an FPGA bitstream in a few hours. The physical design and package guys would have a bit more work to do, but it would still be maybe a week before it taped out.

Quote
And previously 32-bit processors could address more thought PAE.  You can obviously make whatever CPUs you like.

That lets you run a number of programs at the same time which in total use more than 4 GB of RAM. It doesn't help an existing individual program like Firefox or a linker or a chess engine that is running out of memory *at all*.

Quote
That just furthers the point that abstract classifications are mostly useless.

No, it further illustrates my central point that the PRIMARY defining characteristic of a computer architecture is how much memory a single program can conveniently address as a flat address space with no segments, no overlays, just a simple pointer that acts like an integer and you can do arithmetic on it.

It doesn't matter that some computers in that family have less physical memory than a program can address or that other computers in that family have more physical memory than a single program can address. What matters is the abstract model the program (and programmer) sees.
 

Offline rrinker

  • Super Contributor
  • ***
  • Posts: 2046
  • Country: us
Re: Microcontrollers memory
« Reply #57 on: January 02, 2019, 08:23:17 pm »
 Somehow talking about old CPUs is always 8080 and Z80. How about the RCA CDP1802? It has pretty much strictly an 8 bit CPU, but it had an array of 16 registers, each 16 bits wide, any of which could be the program counter, or the stack pointer. ANd switched at runtime (there was a SEX opcode - SEt X. PC change was the less interesting SETP opcode). ANd the instruction set was VERY straightforward - in hex. The 8080 was also pretty straightforward - in octal. The 1802 would have a group of instructions where the first hex digit (high 4 bits) was the instruction and the lower 4 bits specified the register or port. Super easy to memorize. Address bus was 16 bits, with 8 lines and a latch, data bus was 8 bits.
 Very clearly an 8 bit CPU, regardless of the register size. The criteria for "reclassifying" - well, it's sort of already been done, from the moment they classified the 8088 as a 16 bit CPU. Yes, it works on 16 bits internally, but it's a pretty poor 16 bit CPU because the data bus is only 8 bits wide. Made sense at the time, used the same peripheral chips as the 8088/8085, all of which only worked with an 8 bit data bus. Simplified design and reduced overall cost, but at a penalty. TO reclassify somethign even less 16 bit than the 8088 as a 1 bit CPU is madness. So what if a Z80 can multiple 16 bit numbers directly? How many clock cycles was that? There was a good article back in the day comparing the use of the Z80's LDDR and LDIR vs the small routine that would be needed on another CPU, in thic case the 1802. At the same clock speed, the 1802 small program was faster than the one Z80 instruction. I don;t recall if there was a similar comparison to code to multiply 16 bit numbers vs the single instruction.  But to decide 'bitness' of the CPU based on how many bits it could add/subtract/multiply/divide in a single instruction is just plain silly - internally that was many clock cycles to perform that operation, which is very little different from a short program that uses multiple instructions, but each instruction operates in 2 or 3 clock cycles. I mean, you cna certainly write math routines that do 64 bit math on an 8 bit CPU - that doesn;t make it a 64 bit processor. And those built in more complex instructions in the Z80 didn;t turn it into a next level CPU, really. It's just that they incorporated that 'code' in the execution unit.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14299
  • Country: fr
Re: Microcontrollers memory
« Reply #58 on: January 02, 2019, 08:39:23 pm »
How about the RCA CDP1802? It has pretty much strictly an 8 bit CPU, but it had an array of 16 registers, each 16 bits wide, any of which could be the program counter, or the stack pointer. ANd switched at runtime (there was a SEX opcode - SEt X. PC change was the less interesting SETP opcode). ANd the instruction set was VERY straightforward - in hex.

Wow! This is actually the CPU that I learned the internals of a CPU with. Was named "COSMAC".
Its architecture made it easy to understand all the internal aspects AFAIK, and exactly how each instruction translated to microcode.
As it was entirely static, you could switch the clock by hand and really inspect its behavior clock pulse by clock pulse without the need for a logic analyzer.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #59 on: January 03, 2019, 01:51:46 am »
The criteria for "reclassifying" - well, it's sort of already been done, from the moment they classified the 8088 as a 16 bit CPU. Yes, it works on 16 bits internally, but it's a pretty poor 16 bit CPU because the data bus is only 8 bits wide. Made sense at the time, used the same peripheral chips as the 8088/8085, all of which only worked with an 8 bit data bus. Simplified design and reduced overall cost, but at a penalty.

Not every application of a computer requires the maximum possible speed. Otherwise you wouldn't see people plugging 16 MHz Arduinos into 4 GHz PCs and actually doing useful things with them.

The #1 lesson of the last 40 years (if not more) in the computer business is that software lives forever if there is compatible and competitive hardware for it to run on.

You can take a program that ran on that shitty 4.77 MHz 8088 in 1979 and run it without modification and at native speed (not emulated) on a 5 GHz i7, which is going to be something around 20000 to 30000 times faster.

This is what made Microsoft and Intel two of the richest companies in the world.

Quote
TO reclassify somethign even less 16 bit than the 8088 as a 1 bit CPU is madness. So what if a Z80 can multiple 16 bit numbers directly? How many clock cycles was that? There was a good article back in the day comparing the use of the Z80's LDDR and LDIR vs the small routine that would be needed on another CPU, in thic case the 1802. At the same clock speed, the 1802 small program was faster than the one Z80 instruction. I don;t recall if there was a similar comparison to code to multiply 16 bit numbers vs the single instruction.  But to decide 'bitness' of the CPU based on how many bits it could add/subtract/multiply/divide in a single instruction is just plain silly - internally that was many clock cycles to perform that operation, which is very little different from a short program that uses multiple instructions, but each instruction operates in 2 or 3 clock cycles. I mean, you cna certainly write math routines that do 64 bit math on an 8 bit CPU - that doesn;t make it a 64 bit processor. And those built in more complex instructions in the Z80 didn;t turn it into a next level CPU, really. It's just that they incorporated that 'code' in the execution unit.

You are confusing the instruction set that software is written with and ONE PARTICULAR IMPLEMENTATION of that instruction set.

That's an easy trap to fall into, because in those days every new faster shinier CPU had a completely new and incompatible instruction set.

There was only ever one implementation of the Z80 instruction set and, yes, it used a ridiculously large number of clock cycles for many operations, which is why I could often beat it for speed with visually inferior 6502 programs.

But it would be trivial today (or even in the late 1980s) to make a chip that ran unchanged Z80 programs at 1 clock cycle per instruction. And in the mid 1990s you could make a chip that ran three or four Z80 instructions per clock cycle.

No one did this, of course, because the Z80 is only a 16 bit instruction set, and as such can only conveniently use 64 KB of memory, which was by then far too little to be interesting for people who want or need fast computers. It was also simply a very bad instruction set, especially if you wanted to run a modern programming language such as C or Pascal needing stack frames, recursion, structs etc.

Even if you're happy with a 64 KB limit today, there are much better instruction sets around than Z80, such as AVR or MSP430, both of which probably use about the same number of transistors as a Z80 (and all have about 32 bytes of registers) and are far more pleasant to program.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Microcontrollers memory
« Reply #60 on: January 03, 2019, 10:03:51 am »
Quote
There was only ever one implementation of the Z80 instruction set
That's an interesting assertion.  A lot of companies ended up selling Z80-compatible CPUs, and I have no idea whether they were all licensed and identical to the Zilog implementation or not, especially WRT instruction timings and that 4-bit ALU (Z80 timing was usually the same or better than 8080, in spite of having the half-sized ALU, right?) And Zilog didnt' stand still, and has done follow-on processors that are supersets of the Z80 instruction set.  Still sold today.
I'm especially wondering about the "Z80 mode" of the NEC "V-20" CPU that had a short popularity as an "upgrade" 8088-compatible processor for early IBM PCs and compatibles.  NEC also took the Z80 and enhanced it; even today you can get chips that are (rather depressingly) Z80-like via Renesas RL78 (with bells!  and Whistles! (and fewer clocks/instruction))
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #61 on: January 03, 2019, 11:21:50 am »
Quote
There was only ever one implementation of the Z80 instruction set
That's an interesting assertion.  A lot of companies ended up selling Z80-compatible CPUs, and I have no idea whether they were all licensed and identical to the Zilog implementation or not, especially WRT instruction timings

I confess that I have no idea. I didn't follow the 8080/Z80 and compatible successors all that closely. Another poster seemed confident he knew the number of clock cycles for any Z80 instruction -- and that they were shocking and the same for all of them.

I could tell you about the 6502 and 65C02 and 65C816 and I see Mouser will today still happily sell you a W65C816S6PG-14 in a PDIP-40 and running at 14 MHz for $7.95 ($6.95 for 10, $5.87 for 250+). Or a bit cheaper in a more modern package. Or you can license the Verilog. It seems to have pretty much the same timings the original 6502 had, with one clock cycle per instruction or data byte read or written, and a 2 cycle minimum. https://www.mouser.com/datasheet/2/436/w65c816s-1062580.pdf dated November 09, 2018.
 

Offline rrinker

  • Super Contributor
  • ***
  • Posts: 2046
  • Country: us
Re: Microcontrollers memory
« Reply #62 on: January 03, 2019, 04:03:36 pm »
 There are still Z80 variations being sold as well. Some of them turn the system into a single chip (plus memory) solution by including the Z80 CPU and the glue logic in one chip. Products are still being sold with a Z80 CPU at their heart.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: Microcontrollers memory
« Reply #63 on: January 03, 2019, 04:06:48 pm »
There are still Z80 variations being sold as well. Some of them turn the system into a single chip (plus memory) solution by including the Z80 CPU and the glue logic in one chip. Products are still being sold with a Z80 CPU at their heart.
Some of those devices have the Z80 core running at hundreds of MHz. I think I even saw one exceeding 1GHz a couple of years ago.
 

Offline rrinker

  • Super Contributor
  • ***
  • Posts: 2046
  • Country: us
Re: Microcontrollers memory
« Reply #64 on: January 03, 2019, 04:12:59 pm »
How about the RCA CDP1802? It has pretty much strictly an 8 bit CPU, but it had an array of 16 registers, each 16 bits wide, any of which could be the program counter, or the stack pointer. ANd switched at runtime (there was a SEX opcode - SEt X. PC change was the less interesting SETP opcode). ANd the instruction set was VERY straightforward - in hex.

Wow! This is actually the CPU that I learned the internals of a CPU with. Was named "COSMAC".
Its architecture made it easy to understand all the internal aspects AFAIK, and exactly how each instruction translated to microcode.
As it was entirely static, you could switch the clock by hand and really inspect its behavior clock pulse by clock pulse without the need for a logic analyzer.

 Myself as well. It was the basis for my very first computer, but even before that, I came across an issue of Radio Electronics magazine which described the operation of the 1801 - the predecessor part, it was a 2 chip solution instead of single chip like the 1802, and I read and re-read that article until I truly understood what was going on. When I finally was able to purchase a computer, it really came down to which of two common 1802 based systems it was going to be. Super easy to understand, compared to some of the others. When 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.  In the interim I learned Z80 owing to a friend owning a TRS-80  and buying the editor-assembler package and having no idea what it was for. And the system design articles in various magazines. I eventually did own a TRS-80 myself and did plenty of Z80 stuff, but when I eventually went MS-DOS, one beyond the 8088 I pretty much threw up my hands. The instruction sets on modern Intel CPUs are just ridiculous, and understanding the inner workings is a full time job, not something you can just easily do on the side to improve your programming skills - and assembly on such a chip? Right! That's why I love the 8 bit micros, they are a return to the time when you could understand what was going on as well as how to do it.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #65 on: January 04, 2019, 03:22:36 am »
That's why I love the 8 bit micros, they are a return to the time when you could understand what was going on as well as how to do it.

I agree that the 8 bit micros are very easy to understand what any individual instruction does, and also there are not many instructions to learn. That is good.

The problem with them is that it's very difficult to understand how to *use* those instructions to attain your end goal of writing a game or accounting package or web server or whatever. It's like someone handing you a dozen different lego (or Meccano) parts and telling you to make the Golden Gate Bridge, just using as many of each part as you need.

There are a whole host of CPU instruction sets that are very nearly as easy to understand as 6800 or 6502 or Z80 or 1802, but much much easier to work with to build large programs (or to efficiently target from a high level language compiler): PDP11, MSP430, Super-H, ARM2, Thumb1, MIPS2, RISC-V. *Maybe* original M68000, though it adds a bit of complexity.

M6809 is good too, both for the assembly language programmer and the compiler, but had the misfortune to be an 8/16 bit CPU that came when people already wanted full 16 bit CPUs.
« Last Edit: January 04, 2019, 06:20:56 am by brucehoult »
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Microcontrollers memory
« Reply #66 on: January 04, 2019, 04:31:29 am »
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).
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Microcontrollers memory
« Reply #67 on: January 04, 2019, 05:43:42 am »
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).

Language wars are so passé....

Programming languages are like girlfriends/boyfriends/partners. They are all basically the same, products of their time, each with their own nuances and foibles.

Your preferred language will be old and tired and loose its beauty soon enough..... Or quicker, if it is Perl :D






Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Microcontrollers memory
« Reply #68 on: January 04, 2019, 07:19:07 am »
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).

Language wars are so passé....

Programming languages are like girlfriends/boyfriends/partners. They are all basically the same, products of their time, each with their own nuances and foibles.

Your preferred language will be old and tired and loose its beauty soon enough..... Or quicker, if it is Perl :D

My first one was 6502 assembly :P already outdated and commercially useless when I picked it up :-DD but it did force me to learn how computers work on the fundamental, lowest level. Average BASIC victims never seem to grasp basic (HA!) stuff like base 16 encoding, endianness, pointers, stack, caches, busses. Sure, most learn patterns and algorithms, but will struggle with fundamentals for the rest of their lives. You could argue Javascript is todays BASIC - my browser (Vivaldi) is written in React and stuff like resizing main window can take up to 2 seconds on multicore 4GHz CPU |O
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #69 on: January 04, 2019, 07:37:40 am »
My first one was 6502 assembly :P already outdated and commercially useless when I picked it up :-DD but it did force me to learn how computers work on the fundamental, lowest level. Average BASIC victims never seem to grasp basic (HA!) stuff like base 16 encoding, endianness, pointers, stack, caches, busses. Sure, most learn patterns and algorithms, but will struggle with fundamentals for the rest of their lives.

I'm a firm believer that people should learn assembly language very early on. If you use the standard C library you can start right from HelloWorld and in fact do anything. Learn C at the same time, and how to write some functions in C and some in assembly language and call them from each other and what every C construct translates to in assembly language (and machine code).
 
The following users thanked this post: JPortici

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Microcontrollers memory
« Reply #70 on: January 04, 2019, 10:53:18 am »
I am here to throw a few wrenches into the mix:

1. It is possible for external bus connections to convert a Harvard processor into a Von Neumann machine: just point the instruction and data memory to the same piece of physical hardware on the bus.
2. Most modern ARM cores, bar a few bottom level lowest end ones like Cortex-M0, are Harvard cores. They act Von Neumann simply because the external bus is implemented in such a way.
3. It is even possible to turn a Von Neumann processor into a Harvard machine, if the processor gives enough information in control lines for the bus to decide the same address to different hardware based on processor state.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: Microcontrollers memory
« Reply #71 on: January 04, 2019, 10:59:53 am »
I am here to throw a few wrenches into the mix:

1. It is possible for external bus connections to convert a Harvard processor into a Von Neumann machine: just point the instruction and data memory to the same piece of physical hardware on the bus.
2. Most modern ARM cores, bar a few bottom level lowest end ones like Cortex-M0, are Harvard cores. They act Von Neumann simply because the external bus is implemented in such a way.
3. It is even possible to turn a Von Neumann processor into a Harvard machine, if the processor gives enough information in control lines for the bus to decide the same address to different hardware based on processor state.
Which comes down to "as soon as you add a little complexity to a core, like cache, the distinction between Harvard and Von Neumann becomes very blurred".
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Microcontrollers memory
« Reply #72 on: January 04, 2019, 05:29:21 pm »
I am here to throw a few wrenches into the mix:

1. It is possible for external bus connections to convert a Harvard processor into a Von Neumann machine: just point the instruction and data memory to the same piece of physical hardware on the bus.
2. Most modern ARM cores, bar a few bottom level lowest end ones like Cortex-M0, are Harvard cores. They act Von Neumann simply because the external bus is implemented in such a way.
3. It is even possible to turn a Von Neumann processor into a Harvard machine, if the processor gives enough information in control lines for the bus to decide the same address to different hardware based on processor state.
Which comes down to "as soon as you add a little complexity to a core, like cache, the distinction between Harvard and Von Neumann becomes very blurred".
I am not even touching the core, the memory or the peripherals, just mucking around with the address decoder, hooking odd CPU control lines and status signals into it and things suddenly gets very muddy.
 

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #73 on: January 12, 2019, 09:22:57 pm »
I have one last question:

I have saw in some books, that the size of ROM and RAM is given like (2^n)*m, where m is the length of the word. But when we buy let's say ROM the only information we get is size like 1 MB ROM or similiar. Why is that?
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Microcontrollers memory
« Reply #74 on: January 14, 2019, 12:07:02 am »
... when we buy ... ROM the only information we get is size like 1 MB ROM or similiar. Why is that?

You need to work on your ROM buying skills :)
 

Offline nForceTopic starter

  • Frequent Contributor
  • **
  • Posts: 393
  • Country: ee
Re: Microcontrollers memory
« Reply #75 on: January 14, 2019, 07:19:52 pm »
I have not see any other technical data at ROM chips.
 

Offline rrinker

  • Super Contributor
  • ***
  • Posts: 2046
  • Country: us
Re: Microcontrollers memory
« Reply #76 on: January 14, 2019, 08:42:33 pm »
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.

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #77 on: January 14, 2019, 10:15:58 pm »
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?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Microcontrollers memory
« Reply #78 on: January 15, 2019, 12:02:09 am »
Quote
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.
Quote
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.)
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #79 on: January 15, 2019, 03:05:40 am »
Quote
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Microcontrollers memory
« Reply #80 on: January 15, 2019, 08:09:32 am »
Quote
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Microcontrollers memory
« Reply #81 on: January 15, 2019, 08:14:52 am »
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

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #82 on: January 15, 2019, 09:31:03 am »
Quote
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.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Microcontrollers memory
« Reply #83 on: January 15, 2019, 11:06:48 am »
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?
« Last Edit: January 15, 2019, 11:11:54 am by legacy »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #84 on: January 15, 2019, 11:40:56 am »
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.

Quote
*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.
 

Offline rrinker

  • Super Contributor
  • ***
  • Posts: 2046
  • Country: us
Re: Microcontrollers memory
« Reply #85 on: January 15, 2019, 04:05:03 pm »
 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.

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #86 on: January 15, 2019, 08:04:06 pm »
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.
 

Offline macboy

  • Super Contributor
  • ***
  • Posts: 2252
  • Country: ca
Re: Microcontrollers memory
« Reply #87 on: January 16, 2019, 03:49:52 pm »
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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #88 on: January 16, 2019, 04:40:03 pm »
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.
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3632
  • Country: us
Re: Microcontrollers memory
« Reply #89 on: January 16, 2019, 04:55:08 pm »
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.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: Microcontrollers memory
« Reply #90 on: January 16, 2019, 05:01:13 pm »
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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #91 on: January 16, 2019, 05:34:22 pm »
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.
« Last Edit: January 16, 2019, 05:38:31 pm by brucehoult »
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3632
  • Country: us
Re: Microcontrollers memory
« Reply #92 on: January 16, 2019, 06:03:28 pm »
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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3998
  • Country: nz
Re: Microcontrollers memory
« Reply #93 on: January 16, 2019, 07:03:41 pm »
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.
« Last Edit: January 16, 2019, 07:50:21 pm by brucehoult »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Microcontrollers memory
« Reply #94 on: January 17, 2019, 11:53:33 am »
Quote
Classifying CPUs, especially early ones, isn't easy. I'll throw out a very difficult example: the Motorola 68000, ca. 1979.
Yes.
Quote
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]
Quote
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.)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf