Microcontrollers memory - Page 1
Forum section: electronics / general

author: nForce
author_rank: Frequent Contributor
timestamp: December 27, 2018, 01:27:33 pm
content: 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.

author: martinayotte
author_rank: Regular Contributor
timestamp: December 27, 2018, 01:59:46 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: December 27, 2018, 02:32:05 pm
content: 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.

author: Kleinstein
author_rank: Super Contributor
timestamp: December 27, 2018, 04:10:36 pm
content: 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.

author: hans
author_rank: Super Contributor
timestamp: December 27, 2018, 04:14:46 pm
content: 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 theoptionto 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.

author: boB
author_rank: Frequent Contributor
timestamp: December 27, 2018, 04:26:18 pm
content: Quote from: hans on December 27, 2018, 04:14:46 pmWasn'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

author: tsman
author_rank: Frequent Contributor
timestamp: December 27, 2018, 04:36:17 pm
content: It depends on the uC you're using.Quote from: nForce on December 27, 2018, 01:27:33 pmThe 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.

author: rstofer
author_rank: Super Contributor
timestamp: December 27, 2018, 05:06:30 pm
content: Quote from: boB on December 27, 2018, 04:26:18 pmNo, data and instructions are in the same memory space so they are von Neumann architecture.QuoteStill von Neumann...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.pdfThere 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.

author: nForce
author_rank: Frequent Contributor
timestamp: December 27, 2018, 06:40:38 pm
content: 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: December 27, 2018, 07:04:40 pm
content: 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

author: rstofer
author_rank: Super Contributor
timestamp: December 27, 2018, 10:08:59 pm
content: Quote from: nForce on December 27, 2018, 06:40:38 pmOf 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.

author: nForce
author_rank: Frequent Contributor
timestamp: December 28, 2018, 12:51:05 pm
content: 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?

author: JPortici
author_rank: Super Contributor
timestamp: December 28, 2018, 01:04:51 pm
content: Quote from: hans on December 27, 2018, 04:14:46 pmActually, 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?

author: nctnico
author_rank: Super Contributor
timestamp: December 28, 2018, 06:01:06 pm
content: Quote from: hans on December 27, 2018, 04:14:46 pmNo. 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.

author: rstofer
author_rank: Super Contributor
timestamp: December 28, 2018, 06:03:42 pm
content: Quote from: nForce on December 28, 2018, 12:51:05 pmThe 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-8085At 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.

author: nForce
author_rank: Frequent Contributor
timestamp: December 28, 2018, 06:37:21 pm
content: QuoteYou mean the accumulator, which stores an operand for ALU?

author: JPortici
author_rank: Super Contributor
timestamp: December 28, 2018, 06:52:19 pm
content: Quote from: nForce on December 28, 2018, 12:51:05 pmthere was a fun thread about this not many months agowas 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

author: boB
author_rank: Frequent Contributor
timestamp: December 28, 2018, 09:23:27 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: December 28, 2018, 09:37:38 pm
content: Quote from: nForce on December 28, 2018, 06:37:21 pmFor 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.

author: legacy
author_rank: Super Contributor
timestamp: December 29, 2018, 12:42:31 am
content: Quote from: boB on December 28, 2018, 09:23:27 pm(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*"

author: boB
author_rank: Frequent Contributor
timestamp: December 29, 2018, 02:03:53 am
content: Quote from: legacy on December 29, 2018, 12:42:31 amYes ! 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 spendbillions of dollars.And I certainly remember the DSP56001's X and Y memory.

author: ataradov
author_rank: Super Contributor
timestamp: December 29, 2018, 02:06:33 am
content: Quote from: boB on December 29, 2018, 02:03:53 amThere is dual port RAM in most FPGAs.

author: boB
author_rank: Frequent Contributor
timestamp: December 29, 2018, 02:16:49 am
content: Quote from: ataradov on December 29, 2018, 02:06:33 amReally ? 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.

author: ataradov
author_rank: Super Contributor
timestamp: December 29, 2018, 02:20:50 am
content: Quote from: boB on December 29, 2018, 02:16:49 amIt 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.

author: rstofer
author_rank: Super Contributor
timestamp: December 29, 2018, 02:29:27 am
content: Quote from: nForce on December 28, 2018, 06:37:21 pmMaybe...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.

author: brucehoult
author_rank: Super Contributor
timestamp: December 29, 2018, 02:55:06 am
content: Quote from: rstofer on December 29, 2018, 02:29:27 amALU 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.

author: nctnico
author_rank: Super Contributor
timestamp: December 29, 2018, 11:41:21 am
content: AFAIK the number of bits of a CPU is the width of the data bus.

author: nForce
author_rank: Frequent Contributor
timestamp: December 29, 2018, 12:42:19 pm
content: 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?

author: legacy
author_rank: Super Contributor
timestamp: December 29, 2018, 12:51:32 pm
content: Quote from: nctnico on December 29, 2018, 11:41:21 am(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 cyclesyesterday, 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)

author: nctnico
author_rank: Super Contributor
timestamp: December 29, 2018, 02:08:01 pm
content: Quote from: legacy on December 29, 2018, 12:51:32 pmI wrote the CPU. Not the memory interface!

author: legacy
author_rank: Super Contributor
timestamp: December 29, 2018, 02:58:09 pm
content: Quote from: nctnico on December 29, 2018, 02:08:01 pmyou wrote "data bus". Technically even the memory interface is a "data bus"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

author: NorthGuy
author_rank: Super Contributor
timestamp: December 29, 2018, 03:17:00 pm
content: It is often better to avoid classifying things. Classification is only useful when the results of the classification are needed for other things.

author: rstofer
author_rank: Super Contributor
timestamp: December 29, 2018, 09:44:11 pm
content: 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.

author: nForce
author_rank: Frequent Contributor
timestamp: December 29, 2018, 09:49:57 pm
content: Quote from: nForce on December 29, 2018, 12:42:19 pm

author: ataradov
author_rank: Super Contributor
timestamp: December 29, 2018, 09:51:51 pm
content: Quote from: rstofer on December 29, 2018, 09:44:11 pmBut 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.

author: coppice
author_rank: Super Contributor
timestamp: December 29, 2018, 11:26:25 pm
content: Quote from: rstofer on December 29, 2018, 09:44:11 pmBit 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).

author: nForce
author_rank: Frequent Contributor
timestamp: December 30, 2018, 03:20:37 pm
content: I will be happy if someone answers my question.

author: brucehoult
author_rank: Super Contributor
timestamp: December 30, 2018, 03:47:04 pm
content: Quote from: nForce on December 30, 2018, 03:20:37 pmWhich 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.

author: nForce
author_rank: Frequent Contributor
timestamp: December 30, 2018, 04:28:52 pm
content: Quote from: brucehoult on December 30, 2018, 03:47:04 pmNo, the other one, here:Quote

author: rstofer
author_rank: Super Contributor
timestamp: December 30, 2018, 05:25:51 pm
content: Quote from: nForce on December 30, 2018, 04:28:52 pmAs 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.

author: nForce
author_rank: Frequent Contributor
timestamp: December 30, 2018, 05:42:55 pm
content: 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?

author: NorthGuy
author_rank: Super Contributor
timestamp: December 30, 2018, 06:51:37 pm
content: Quote from: nForce on December 30, 2018, 05:42:55 pmThere 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.Quote from: nForce on December 30, 2018, 05:42:55 pmModern 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

author: rstofer
author_rank: Super Contributor
timestamp: December 30, 2018, 07:38:56 pm
content: Quote from: nForce on December 30, 2018, 05:42:55 pmI 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.QuoteThe 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.

author: westfw
author_rank: Super Contributor
timestamp: December 30, 2018, 08:20:23 pm
content: QuoteI'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.

author: brucehoult
author_rank: Super Contributor
timestamp: December 30, 2018, 08:35:02 pm
content: Quote from: rstofer on December 30, 2018, 05:25:51 pmI 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!

author: brucehoult
author_rank: Super Contributor
timestamp: December 30, 2018, 08:40:03 pm
content: Quote from: westfw on December 30, 2018, 08:20:23 pmThe 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: December 30, 2018, 08:48:40 pm
content: ... 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).

author: westfw
author_rank: Super Contributor
timestamp: December 30, 2018, 09:44:04 pm
content: QuoteSure, 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.)

author: brucehoult
author_rank: Super Contributor
timestamp: December 30, 2018, 09:50:33 pm
content: Quote from: westfw on December 30, 2018, 09:44:04 pmNot just 8 bit. The Z80 instruction set has instructions to add or subtract two 16 bit values.

author: westfw
author_rank: Super Contributor
timestamp: December 31, 2018, 01:19:41 am
content: QuoteIs 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...

author: nForce
author_rank: Frequent Contributor
timestamp: December 31, 2018, 08:55:59 pm
content: ThanksWhat 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?

author: ataradov
author_rank: Super Contributor
timestamp: December 31, 2018, 08:58:28 pm
content: Quote from: nForce on December 31, 2018, 08:55:59 pmIt 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.

author: nForce
author_rank: Frequent Contributor
timestamp: December 31, 2018, 09:22:59 pm
content: Quote from: ataradov on December 31, 2018, 08:58:28 pmWhy then the 64-bit processor can address 2^64 addresses?

author: ataradov
author_rank: Super Contributor
timestamp: December 31, 2018, 09:25:22 pm
content: Quote from: nForce on December 31, 2018, 09:22:59 pmThey 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.

author: brucehoult
author_rank: Super Contributor
timestamp: December 31, 2018, 11:23:37 pm
content: Quote from: ataradov on December 31, 2018, 09:25:22 pmYou'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.

author: ataradov
author_rank: Super Contributor
timestamp: December 31, 2018, 11:26:50 pm
content: Quote from: brucehoult on December 31, 2018, 11:23:37 pmNot 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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 01, 2019, 12:09:34 am
content: Quote from: ataradov on December 31, 2018, 11:26:50 pmThat'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.QuoteThat 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*.QuoteNo, 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.

author: rrinker
author_rank: Super Contributor
timestamp: January 02, 2019, 08:23:17 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 02, 2019, 08:39:23 pm
content: Quote from: rrinker on January 02, 2019, 08:23:17 pmWow! 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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 03, 2019, 01:51:46 am
content: Quote from: rrinker on January 02, 2019, 08:23:17 pmNot 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.QuoteYou 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.

author: westfw
author_rank: Super Contributor
timestamp: January 03, 2019, 10:03:51 am
content: QuoteThat'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))

author: brucehoult
author_rank: Super Contributor
timestamp: January 03, 2019, 11:21:50 am
content: Quote from: westfw on January 03, 2019, 10:03:51 amI 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.pdfdated November 09, 2018.

author: rrinker
author_rank: Super Contributor
timestamp: January 03, 2019, 04:03:36 pm
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: January 03, 2019, 04:06:48 pm
content: Quote from: rrinker on January 03, 2019, 04:03:36 pmSome 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.

author: rrinker
author_rank: Super Contributor
timestamp: January 03, 2019, 04:12:59 pm
content: Quote from: SiliconWizard on January 02, 2019, 08:39:23 pmMyself 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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 04, 2019, 03:22:36 am
content: Quote from: rrinker on January 03, 2019, 04:12:59 pmI 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.

author: Rasz
author_rank: Super Contributor
timestamp: January 04, 2019, 04:31:29 am
content: Quote from: brucehoult on January 04, 2019, 03:22:36 am6502 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).

author: hamster_nz
author_rank: Super Contributor
timestamp: January 04, 2019, 05:43:42 am
content: Quote from: Rasz on January 04, 2019, 04:31:29 amLanguage 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

author: Rasz
author_rank: Super Contributor
timestamp: January 04, 2019, 07:19:07 am
content: Quote from: hamster_nz on January 04, 2019, 05:43:42 amMy first one was 6502 assemblyalready outdated and commercially useless when I picked it upbut 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

author: brucehoult
author_rank: Super Contributor
timestamp: January 04, 2019, 07:37:40 am
content: Quote from: Rasz on January 04, 2019, 07:19:07 amI'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).

author: technix
author_rank: Super Contributor
timestamp: January 04, 2019, 10:53:18 am
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: January 04, 2019, 10:59:53 am
content: Quote from: technix on January 04, 2019, 10:53:18 amWhich 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".

author: technix
author_rank: Super Contributor
timestamp: January 04, 2019, 05:29:21 pm
content: Quote from: coppice on January 04, 2019, 10:59:53 amI 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.

author: nForce
author_rank: Frequent Contributor
timestamp: January 12, 2019, 09:22:57 pm
content: 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?

author: NorthGuy
author_rank: Super Contributor
timestamp: January 14, 2019, 12:07:02 am
content: Quote from: nForce on January 12, 2019, 09:22:57 pmYou need to work on your ROM buying skills

author: nForce
author_rank: Frequent Contributor
timestamp: January 14, 2019, 07:19:52 pm
content: I have not see any other technical data at ROM chips.

author: rrinker
author_rank: Super Contributor
timestamp: January 14, 2019, 08:42:33 pm
content: Quote from: Rasz on January 04, 2019, 04:31:29 amYou 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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 14, 2019, 10:15:58 pm
content: Quote from: rrinker on January 14, 2019, 08:42:33 pm99% 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?

author: westfw
author_rank: Super Contributor
timestamp: January 15, 2019, 12:02:09 am
content: QuoteAre 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"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.)

author: brucehoult
author_rank: Super Contributor
timestamp: January 15, 2019, 03:05:40 am
content: Quote from: westfw on January 15, 2019, 12:02:09 amI 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 ALDN BADDSTA BINC AINC BLDN BADCSTA BDEC ADEC BAll 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 #0CLCLDA (B),YADC (A),YSTA (B),YINYLDA (B),YADC (A),YSTA (B),YThat'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.

author: westfw
author_rank: Super Contributor
timestamp: January 15, 2019, 08:09:32 am
content: QuoteDo 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:funcret: SEP normalPC ;; set PC back to caller code to returnfunc: ;; do stuff BR funcret ;; done. set up current PC to be called again and go.

author: westfw
author_rank: Super Contributor
timestamp: January 15, 2019, 08:14:52 am
content: I found some "SCRT" code for 1802 ("Standard Call and Return Technique"?)Code:;*************************************************************************;DESC: STANDARD SEP CALL and RETN;REG USED: SP,PC,SEP CALL;,A(,RETURN,LINK & STACK;*************************************************************************; STANDARD CALLEXITC SEP PC ;GO TO CALLED ROUTINECALLR SEX SP ;SET R(X)GHI LINKSTXD ;SAVE THE CURRENT LINK ONGLO LINKSTXD ;THE STACKGHI PCPHI LINKGLO PCPLO LINKLDA LINKPHI PC ;PICK UP THE SUBROUTINELDA LINKPLO PC ;ADDRESSBR EXITC; STANDARD RETURNEXITR SEP PC ;RETURN TO MAIN PGMRETR GHI LINK ;recover calling program return addrPHI PCGLO LINKPLO PCSEX SPINC SP ;SET THE STACK POINTERLDXAPLO LINK ;RESTORE THE CONTENTS OFLDXPHI LINK ;LINKBR EXITR

author: brucehoult
author_rank: Super Contributor
timestamp: January 15, 2019, 09:31:03 am
content: Quote from: westfw on January 15, 2019, 08:09:32 amI 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.

author: legacy
author_rank: Super Contributor
timestamp: January 15, 2019, 11:06:48 am
content: Quote from: brucehoult on January 15, 2019, 09:31:03 amcheaply area is ok, I get it, but why cheaply energy?Quote from: brucehoult on January 15, 2019, 09:31:03 amthe 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?

author: brucehoult
author_rank: Super Contributor
timestamp: January 15, 2019, 11:40:56 am
content: Quote from: legacy on January 15, 2019, 11:06:48 amBecause 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.QuoteNo.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.

author: rrinker
author_rank: Super Contributor
timestamp: January 15, 2019, 04:05:03 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 15, 2019, 08:04:06 pm
content: Quote from: rrinker on January 15, 2019, 04:05:03 pmIt'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.

author: macboy
author_rank: Super Contributor
timestamp: January 16, 2019, 03:49:52 pm
content: Quote from: nctnico on December 29, 2018, 02:08:01 pmQuote from: rstofer on December 29, 2018, 09:44:11 pmClassifying 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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 16, 2019, 04:40:03 pm
content: Quote from: macboy on January 16, 2019, 03:49:52 pmI 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.

author: helius
author_rank: Super Contributor
timestamp: January 16, 2019, 04:55:08 pm
content: Quote from: brucehoult on January 16, 2019, 04:40:03 pmI'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.

author: coppice
author_rank: Super Contributor
timestamp: January 16, 2019, 05:01:13 pm
content: Quote from: helius on January 16, 2019, 04:55:08 pmSun moved to SPARC well before the 68040 came out. Both Apple and NeXT used the 68040.

author: brucehoult
author_rank: Super Contributor
timestamp: January 16, 2019, 05:34:22 pm
content: Quote from: helius on January 16, 2019, 04:55:08 pmWhat 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.

author: helius
author_rank: Super Contributor
timestamp: January 16, 2019, 06:03:28 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 16, 2019, 07:03:41 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: January 17, 2019, 11:53:33 am
content: QuoteYes.QuoteAlso 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]QuoteI 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.)