Author Topic: Microcontrollers memory  (Read 15256 times)

0 Members and 1 Guest are viewing this topic.

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?
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11260
  • 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?
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11260
  • 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
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4037
  • 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.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11260
  • 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
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4037
  • 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.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14476
  • 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.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4037
  • 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: 4199
  • 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))
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4037
  • 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: 8646
  • 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.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4037
  • 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.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4037
  • 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: 8646
  • 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: 3146
  • 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 :)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf