15 ms·

Cool, I really like AVR, but kind of wished there was like a 8-bit RISC-V or something with similar packaging and choices as AVR.

snvzz 4y ago
>a 8-bit RISC-V There's n-bit RISC-V implementations. The registers are still 32 or 64 bit wide, but the ALU is smaller and takes multiple steps. One such implementation is open source, but I sadly don't remember the name and can't find immediately.
- FullyFunctional 4y ago
  There are oh-so-many, but the one you think of might be Olof's SERV (https://github.com/olofk/serv https://github.com/olofk/serv)
- freemint 4y ago
  Yeah but the registers do not get smaller in that implementation.
ChuckNorris89 4y ago
Why is HN obsessed with reinventing the wheel with the new shiny (Rust, Risc-V, etc.) for applications that are perfectly served by mature, battle proven solutions which provide a reliable, cheap and quick time to market. AVR is today a pretty niche solution, but for it's niche it's better than Risc-V for its mature silicon and tooling, robust analog and digital 5V tolerant I/O, robust CPU and peripheral clocking, cycle accurate simulators, and experienced dev pool. The over 20 year old gas boiler my grandma has, is "powered" by an DIP packaged AVR chip and does the job just fine for controlling a couple of valves, LEDs, relays, and a PID loop. Same for the old elevator on my university. These kinds of apps is where the simplicity of AVR shines. Source: former AVR dev
- FullyFunctional 4y ago
  I don't think anyone would seriously claim that the existing 8-bit architectures represent any optimal design point (AVR definitely does not). A constant cycle of innovation is what characterize all technology progress.
  - ChuckNorris89 4y ago
    Let's not let perfect be the enemy of good. A lot of embedded devices and white goods are profitable to build and sell in the economies of scale, because they can reuse an old microcontroller design like the AVR, which is not the pinnacle anymore, but that's been proven over decades to be robust and reliable for specific use cases. Technology progress is happening regardless, but not all products benefit from switching to the new shiny. Especially legacy boring products. Some AVR perks like 5V tolerant I/O, and pins able to sink high currents, is something rarely found on newer more modern ARM or RISC-V chips which tend to be more "fragile" in some regards. So this is why sich older chips could still be advantageous.
    - HeyLaughingBoy 4y ago
      > So this is why sich older chips could still be advantageous Yup. I just found myself having to buffer an ESP32's output with an LS245!! because the old-school LED display I needed to drive required more current on its logic inputs than the ESP could source. An AVR would have driven it just fine. And before anyone asked why I used a 74LS245 instead of a more appropriate level converter, I had to go with what's in stock these days and this design will have at most 3 units built.
  - nousermane 4y ago
    AVR might be not optimal in mathematical sense, but it feels so nice: - Tons of registers, up to a point where there are attiny parts with no RAM, and they are fairly usable; - Great code density for embedded - single-instruction atomic GPIO bit sets/bit resets, branch-if-bit-set/reset, etc; - In general, pretty approachable instruction set, if one fancies writing some assembly/machine code directly, while GCC also targets this ISA without issues; - Brilliant JTAG-like hardware debugging interface that uses zero extra pins (reset pin is reused), and hardware-wise, interfacing requires serial port + one diode, that's it [0] [0] https://github.com/dcwbrown/dwire-debug https://github.com/dcwbrown/dwire-debug
- alar44 4y ago
  In my opinion, it's because new programmers find C scary due to the prevalence of Python. There's no need to learn anything anymore with all of our RAM and storage. Programming has essentially turned into scripting. Today you load the boiler library and type start().
  - ChuckNorris89 4y ago
    >Today you load the boiler library and type start(). Not when you have safety critical real time applications that need to be certified. Gas boiler control isn't move fast and break things web development. Unless you want to blow yourself up. That's why old AVR solutions are still used. They've been certified once, they work just fine for this purpose even on newer products. So you go with it. It's a slow moving industry for this reason. Also, embedded dev is way more than writing C or python code and how many "bits" your CPU core has. You need to take into account clocking sources and stability, analog and digital I/O, on package voltage regulators, tolerance to glitching and brownouts, etc. and for certain applications, AVR chips are way more robust than newer ARM or RISC-V shiny.
    - rtpg 4y ago
      I don’t want to go too much into C vs Rust but loads of C code out there, when it comes time to manipulate strings or do something a bit complicated, ends up a hacky mess. For all the implications you are making about “move fast and break things” in web dev, at least newer tech stacks makes it easier to not completely break your data structures cuz the abstraction ceiling made doing things the right way hard. Of course experienced C programmers “get it”, design their code in a way to avoid these pitfalls, and can right performant, correct code. I just think that it’s easier with a lot of other tools for stuff that’s just a bit complicated
      - ChuckNorris89 4y ago
        I feel you're mixing things up. Not every embedded application requires parsing strings or JSONs like you do with web frameworks. AVRs and 8 bit chips in general are mostly used in various fixed point numerical control applications like CNC, industrial automation, elevator control, and white goods for the home like washing machines, HVAC, and microwave ovens, so for that they're perfect and so is C. All they do is read some buttons and sensors, crunch some basic math, run a state machine, and turn some motors, LEDs and relays ON and OFF. That's it. Complex string manipulations is something you'll never see on an AVR chip in such production applications.
- baybal2 4y ago
  There are Padauks, Holteks, Sonixes and others most EEs in the West never hear about
- stackbutterflow 4y ago
  Why is HN obsessed with reinventing the wheel with the new shiny (Rust, Risc-V, etc.) What else does this "etc" include?
  - deleted 4y ago
    [deleted]
  - lesuorac 4y ago
    Probably eink, is slate not good enough for you?
- vbezhenar 4y ago
  I'm amateur. I decided to go with RP2040 because I have a limited time and I want to understand underlying architecture. ARM is more useful than AVR, because ARM knowledge (even Cortex-M0) is more transferrable to other fields, like my Macbook. Same could be said about RISC-V. It's going to be big. So it's very tempting to learn it once for many different areas. Again same could be said about Rust. I can (theoretically) write microcontroller firmware with Rust, I can write OS with rust, I can write linux app with rust, I can write website with rust. That's very appealing in terms of knowledge transfer. There're so much things which reinvent the wheel. I think that people want to choose one good enough wheel and keep using it. C and C++ are not good enough. Rust might be good enough. ARM is proprietary and not good enough. RISC-V from outside perspective seems to be good enough. Progress has to stop somewhere.
  - ChuckNorris89 4y ago
    >I'm amateur. My point exactly, and that's fine to choose whatever you're more comfortable with for your hobby projects, but when we're talking about actually developing products and shipping millions of units on tight budgets with high constraints, that need to operate flawlessly for decades in harsh environments, you'll realize why using "ye olde faithful" 30 year old AVR core, could make a lot more technical, business and financial sense than the newest shiny ARM based chips that just came out in <current_year>. So, no offense, but amateur hobby work and shipping millions of products that need to be bullet proof, are worlds apart.
    - speed_spread 4y ago
      I've summarized your stance as "real men use C on AVR". Newer technologies such as Rust fundamentally do not solve a technical problem, but a social one. As you say, anything can already be done reliably and cheaply using existing tools and chips _provided you already know the field_. What the new tech brings in is "knowledge scalability" - one can reuse much more of their experience from non-embedded platform and focus on learning the challenges specific to the MCU environment without having to deal with the incidental complexity of low-level programming.
- resonious 4y ago
  If we're talking about Rust and Risc-V specifically, there are pretty straightforward reasons for why people like them so much. Rust: native code with very strong safety guarantees and no garbage collection. I have yet to see another language fit that niche. Risc-V: fully open source processor design, along with a reference implementation and tooling. As far as I know, hardware does not have a history of being free and open. HN is hacker news after all. People like to tinker. Just because something is tried-and-true doesn't mean it can't be improved on or be re-built for practice.
  - ChuckNorris89 4y ago
    >Just because something is tried-and-true doesn't mean it can't be improved on or be re-built for practice. And that's why HN should also consider to look outside of the fast moving tinkerer bubble and realize that if you're trying to sell some white goods profitably there's a reason why the old and tested is used and not the latest shiny. Hardware development is completely different than web development.
    - speed_spread 4y ago
      You made me imagine an npm-like world for FPGA development of custom CPU from thousands of amateur packages. It was both funny anf horrible. Thanks?
      - scoutt 4y ago
        Like this? https://opencores.org/projects https://opencores.org/projects
        speed_spread 4y ago
        No, that's actually super cool! When I think of an npm project, I think of an evergrowing dependency tree covering trivial stuff such as leftpad.
  - socialdemocrat 4y ago
- zozbot234 4y ago
  As I understand it, RV32E is small enough to compete with existing 8 bit designs, and RISC-V architecture designers have settled on that as the smallest reasonable design point. There's been many proposals for a 16-bit adaptation of RISC-V (compared to the existing RV32 and RV64, and the proposed RV128) but the interest just isn't there.
  - hajile 4y ago
    There's a LOT more to this discussion. SiFive claims they can fit a RV32E core into 13.5k gates, but to my knowledge, that's just the core itself without any of the IO, memory, etc. A small 8051 implementation can be made in 2.7k gates with a lot of typical implementations using between 8 and 14k gates (but with a lot of proprietary features not actually in the spec). Setting aside the question of power efficiency of 8-bit cores, the real question becomes one of instruction density as that determines the size of the storage and RAM (increasing these can have dramatic cost differences). To my knowledge, RV32E doesn't have a compressed instruction variant meaning every instruction is 32 bits long. 8051 instructions are between 8 and 24-bits long (generally, 8-bit for math, 16-bit for MOV, and 24-bit for immediates). If you're working mostly on 8 or 16-bit data like a TON of MC work is, then I don't see how RV32E could have any advantage. If you're working with a lot of 32 or 64-bit data, then I can easily see a RV32E chip requiring less space for the same results. A 16-bit only variant of RISC-V that repurposes the remaining 50% of the instruction space (used for marking 32 and 48-bit instructions) would be a much more interesting option here IMO.
    - zozbot234 4y ago
      > To my knowledge, RV32E doesn't have a compressed instruction variant meaning every instruction is 32 bits long. AIUI, the E variant is designed to work quite well with the standard compressed encoding. Of course implementing compressed instruction decode takes some area, too; there will be some crossover point at which the density benefits of compressed instructions will more than pay for the higher complexity of decode.
      - monocasa 4y ago
- socialdemocrat 4y ago
  I am not speaking as someone working in industry but somebody with a hobby interest and as a writer. I have been looking at solutions to reach assembly to beginners. I think Things like Arduino and AVR has been great for beginners in terms of getting solutions up and running. Wiring works fine. My issues is that I have realized that as a platform for teaching assembly it isn’t ideal. RISC-V gives a much friendlier ISA while also offering something which is realistic for modern hardware.
  - a2800276 4y ago
    But wouldn't it be preferable to use a 32bit RISC-V uController or a dirt-cheap ARM core like the RP2040 for teaching? Any 8 bit platform would be specialized either towards legacy support or extreme cost optimization, but not towards beginner ease of use ...
  - HeyLaughingBoy 4y ago
    As someone working in industry, I really have to wonder at the reason for teaching assembly to beginners while the rest of us are trying to move up the abstraction ladder. Care to expound on why you're doing this?
    - ChuckNorris89 4y ago
      Debugging embedded software or even low level software or examining malware is much better at assembly level.
      - HeyLaughingBoy 4y ago
        I see. I don't know much about malware, but I do know a bit about embedded programming and it's been a solid 20 years since assembly has helped me to debug something.
  - pclmulqdq 4y ago
    That is initially what RISC-V was for - it was born out of a teaching ISA that was easy to program and easy to implement in hardware.
- pmarin 4y ago
  HN is a news site, mature, battle proven solutions are not things people are hyped about.
throwaway81523 4y ago
RISC is a 32 or 64 bit arch. There was some discussion of a 16 bit version but it didn't get traction. 8 bits wouldn't really work: who wants an 8 bit cpu with 32 bit wide instructions? From a software perspective I could see some attraction to new 8-bit architectures, but in market terms it is legacy space by now, it seems to me.
Findecanor 4y ago
That AVR has 8-bit registers isn't much of a benefit today. While it might make the AVR's core small, it requires more instructions to operate on 16-bit or 32-bit values — which a lot of code has to. For instance, an "int" in AVR C is 16 bits and because C does "integer promotion", it requires 16-bit semantics even when both operands are char. Despite having wider registers, I believe RISC-V cores could be made quite small too because of how lean its ISA is. As a hobbyist, I use AVR mostly because it is 5V-capable and electrically robust, so it can interface with vintage peripherals without requiring signal-level converters or additional ESD protection. It would be nice to see more competition in this space, for sure.
- gsliepen 4y ago
  While the C standard does say that integer promotion happens, if the result is being cast back to char again, a C compiler will see that it doesn't need to operate on 16 bits and is allowed to optimize the result back to 8 bit operations. See for example: https://godbolt.org/z/zM8reeqrc https://godbolt.org/z/zM8reeqrc
- hajile 4y ago
  I feel like 16-bit MCs aren't popular because they aren't popular. They offer a straight-up 2x performance increase in most applications and something like a 4-10x performance increase with 32-bit numbers (not to mention the space savings from fewer instructions). Despite this, the 16-bit MCs all seem to be rather niche. I'd love for an open RISC-V variant that could fill this gap and allow sourcing of the same ISA from multiple companies.
PaulHoule 4y ago
I dunno. AVR-8 is basically the last 8 bit CPU so it is much better than the CPUs we remember from the 1980s like the Z80, 6502, 6809, in most respects except RAM size. 32 registers is a lot! It also takes advantage of the Harvard architecture and has none of this pipelining and cache BS, most instructions take a cycle so if it runs at 20MHz it is basically running at 20 MIPS. Assembly language is beautiful and thinking about writing C for it makes me want to cry. The one issue is that it has no upgrade path to anything more powerful so if you want something better it is going to be ARM or ESP32 so you might just keep writing portable C.
deleted 4y ago
[deleted]
phendrenad2 4y ago
Why do you want that? What do you think that would look like? What about it appeals to you? Specifically?

snvzz 4y ago

>a 8-bit RISC-V There's n-bit RISC-V implementations. The registers are still 32 or 64 bit wide, but the ALU is smaller and takes multiple steps. One such implementation is open source, but I sadly don't remember the name and can't find immediately.

FullyFunctional 4y ago
There are oh-so-many, but the one you think of might be Olof's SERV (https://github.com/olofk/serv https://github.com/olofk/serv)
freemint 4y ago
Yeah but the registers do not get smaller in that implementation.

ChuckNorris89 4y ago

Why is HN obsessed with reinventing the wheel with the new shiny (Rust, Risc-V, etc.) for applications that are perfectly served by mature, battle proven solutions which provide a reliable, cheap and quick time to market. AVR is today a pretty niche solution, but for it's niche it's better than Risc-V for its mature silicon and tooling, robust analog and digital 5V tolerant I/O, robust CPU and peripheral clocking, cycle accurate simulators, and experienced dev pool. The over 20 year old gas boiler my grandma has, is "powered" by an DIP packaged AVR chip and does the job just fine for controlling a couple of valves, LEDs, relays, and a PID loop. Same for the old elevator on my university. These kinds of apps is where the simplicity of AVR shines. Source: former AVR dev

FullyFunctional 4y ago
I don't think anyone would seriously claim that the existing 8-bit architectures represent any optimal design point (AVR definitely does not). A constant cycle of innovation is what characterize all technology progress.
- ChuckNorris89 4y ago
  Let's not let perfect be the enemy of good. A lot of embedded devices and white goods are profitable to build and sell in the economies of scale, because they can reuse an old microcontroller design like the AVR, which is not the pinnacle anymore, but that's been proven over decades to be robust and reliable for specific use cases. Technology progress is happening regardless, but not all products benefit from switching to the new shiny. Especially legacy boring products. Some AVR perks like 5V tolerant I/O, and pins able to sink high currents, is something rarely found on newer more modern ARM or RISC-V chips which tend to be more "fragile" in some regards. So this is why sich older chips could still be advantageous.
  - HeyLaughingBoy 4y ago
    > So this is why sich older chips could still be advantageous Yup. I just found myself having to buffer an ESP32's output with an LS245!! because the old-school LED display I needed to drive required more current on its logic inputs than the ESP could source. An AVR would have driven it just fine. And before anyone asked why I used a 74LS245 instead of a more appropriate level converter, I had to go with what's in stock these days and this design will have at most 3 units built.
- nousermane 4y ago
  AVR might be not optimal in mathematical sense, but it feels so nice: - Tons of registers, up to a point where there are attiny parts with no RAM, and they are fairly usable; - Great code density for embedded - single-instruction atomic GPIO bit sets/bit resets, branch-if-bit-set/reset, etc; - In general, pretty approachable instruction set, if one fancies writing some assembly/machine code directly, while GCC also targets this ISA without issues; - Brilliant JTAG-like hardware debugging interface that uses zero extra pins (reset pin is reused), and hardware-wise, interfacing requires serial port + one diode, that's it [0] [0] https://github.com/dcwbrown/dwire-debug https://github.com/dcwbrown/dwire-debug
alar44 4y ago
In my opinion, it's because new programmers find C scary due to the prevalence of Python. There's no need to learn anything anymore with all of our RAM and storage. Programming has essentially turned into scripting. Today you load the boiler library and type start().
- ChuckNorris89 4y ago
  >Today you load the boiler library and type start(). Not when you have safety critical real time applications that need to be certified. Gas boiler control isn't move fast and break things web development. Unless you want to blow yourself up. That's why old AVR solutions are still used. They've been certified once, they work just fine for this purpose even on newer products. So you go with it. It's a slow moving industry for this reason. Also, embedded dev is way more than writing C or python code and how many "bits" your CPU core has. You need to take into account clocking sources and stability, analog and digital I/O, on package voltage regulators, tolerance to glitching and brownouts, etc. and for certain applications, AVR chips are way more robust than newer ARM or RISC-V shiny.
  - rtpg 4y ago
    I don’t want to go too much into C vs Rust but loads of C code out there, when it comes time to manipulate strings or do something a bit complicated, ends up a hacky mess. For all the implications you are making about “move fast and break things” in web dev, at least newer tech stacks makes it easier to not completely break your data structures cuz the abstraction ceiling made doing things the right way hard. Of course experienced C programmers “get it”, design their code in a way to avoid these pitfalls, and can right performant, correct code. I just think that it’s easier with a lot of other tools for stuff that’s just a bit complicated
    - ChuckNorris89 4y ago
      I feel you're mixing things up. Not every embedded application requires parsing strings or JSONs like you do with web frameworks. AVRs and 8 bit chips in general are mostly used in various fixed point numerical control applications like CNC, industrial automation, elevator control, and white goods for the home like washing machines, HVAC, and microwave ovens, so for that they're perfect and so is C. All they do is read some buttons and sensors, crunch some basic math, run a state machine, and turn some motors, LEDs and relays ON and OFF. That's it. Complex string manipulations is something you'll never see on an AVR chip in such production applications.
baybal2 4y ago
There are Padauks, Holteks, Sonixes and others most EEs in the West never hear about
stackbutterflow 4y ago
Why is HN obsessed with reinventing the wheel with the new shiny (Rust, Risc-V, etc.) What else does this "etc" include?
- deleted 4y ago
  [deleted]
- lesuorac 4y ago
  Probably eink, is slate not good enough for you?
vbezhenar 4y ago
I'm amateur. I decided to go with RP2040 because I have a limited time and I want to understand underlying architecture. ARM is more useful than AVR, because ARM knowledge (even Cortex-M0) is more transferrable to other fields, like my Macbook. Same could be said about RISC-V. It's going to be big. So it's very tempting to learn it once for many different areas. Again same could be said about Rust. I can (theoretically) write microcontroller firmware with Rust, I can write OS with rust, I can write linux app with rust, I can write website with rust. That's very appealing in terms of knowledge transfer. There're so much things which reinvent the wheel. I think that people want to choose one good enough wheel and keep using it. C and C++ are not good enough. Rust might be good enough. ARM is proprietary and not good enough. RISC-V from outside perspective seems to be good enough. Progress has to stop somewhere.
- ChuckNorris89 4y ago
  >I'm amateur. My point exactly, and that's fine to choose whatever you're more comfortable with for your hobby projects, but when we're talking about actually developing products and shipping millions of units on tight budgets with high constraints, that need to operate flawlessly for decades in harsh environments, you'll realize why using "ye olde faithful" 30 year old AVR core, could make a lot more technical, business and financial sense than the newest shiny ARM based chips that just came out in <current_year>. So, no offense, but amateur hobby work and shipping millions of products that need to be bullet proof, are worlds apart.
  - speed_spread 4y ago
    I've summarized your stance as "real men use C on AVR". Newer technologies such as Rust fundamentally do not solve a technical problem, but a social one. As you say, anything can already be done reliably and cheaply using existing tools and chips _provided you already know the field_. What the new tech brings in is "knowledge scalability" - one can reuse much more of their experience from non-embedded platform and focus on learning the challenges specific to the MCU environment without having to deal with the incidental complexity of low-level programming.
resonious 4y ago
If we're talking about Rust and Risc-V specifically, there are pretty straightforward reasons for why people like them so much. Rust: native code with very strong safety guarantees and no garbage collection. I have yet to see another language fit that niche. Risc-V: fully open source processor design, along with a reference implementation and tooling. As far as I know, hardware does not have a history of being free and open. HN is hacker news after all. People like to tinker. Just because something is tried-and-true doesn't mean it can't be improved on or be re-built for practice.
- ChuckNorris89 4y ago
  >Just because something is tried-and-true doesn't mean it can't be improved on or be re-built for practice. And that's why HN should also consider to look outside of the fast moving tinkerer bubble and realize that if you're trying to sell some white goods profitably there's a reason why the old and tested is used and not the latest shiny. Hardware development is completely different than web development.
  - speed_spread 4y ago
    You made me imagine an npm-like world for FPGA development of custom CPU from thousands of amateur packages. It was both funny anf horrible. Thanks?
    - scoutt 4y ago
      Like this? https://opencores.org/projects https://opencores.org/projects
      - speed_spread 4y ago
        No, that's actually super cool! When I think of an npm project, I think of an evergrowing dependency tree covering trivial stuff such as leftpad.
- socialdemocrat 4y ago
zozbot234 4y ago
As I understand it, RV32E is small enough to compete with existing 8 bit designs, and RISC-V architecture designers have settled on that as the smallest reasonable design point. There's been many proposals for a 16-bit adaptation of RISC-V (compared to the existing RV32 and RV64, and the proposed RV128) but the interest just isn't there.
- hajile 4y ago
  There's a LOT more to this discussion. SiFive claims they can fit a RV32E core into 13.5k gates, but to my knowledge, that's just the core itself without any of the IO, memory, etc. A small 8051 implementation can be made in 2.7k gates with a lot of typical implementations using between 8 and 14k gates (but with a lot of proprietary features not actually in the spec). Setting aside the question of power efficiency of 8-bit cores, the real question becomes one of instruction density as that determines the size of the storage and RAM (increasing these can have dramatic cost differences). To my knowledge, RV32E doesn't have a compressed instruction variant meaning every instruction is 32 bits long. 8051 instructions are between 8 and 24-bits long (generally, 8-bit for math, 16-bit for MOV, and 24-bit for immediates). If you're working mostly on 8 or 16-bit data like a TON of MC work is, then I don't see how RV32E could have any advantage. If you're working with a lot of 32 or 64-bit data, then I can easily see a RV32E chip requiring less space for the same results. A 16-bit only variant of RISC-V that repurposes the remaining 50% of the instruction space (used for marking 32 and 48-bit instructions) would be a much more interesting option here IMO.
  - zozbot234 4y ago
    > To my knowledge, RV32E doesn't have a compressed instruction variant meaning every instruction is 32 bits long. AIUI, the E variant is designed to work quite well with the standard compressed encoding. Of course implementing compressed instruction decode takes some area, too; there will be some crossover point at which the density benefits of compressed instructions will more than pay for the higher complexity of decode.
    - monocasa 4y ago
socialdemocrat 4y ago
I am not speaking as someone working in industry but somebody with a hobby interest and as a writer. I have been looking at solutions to reach assembly to beginners. I think Things like Arduino and AVR has been great for beginners in terms of getting solutions up and running. Wiring works fine. My issues is that I have realized that as a platform for teaching assembly it isn’t ideal. RISC-V gives a much friendlier ISA while also offering something which is realistic for modern hardware.
- a2800276 4y ago
  But wouldn't it be preferable to use a 32bit RISC-V uController or a dirt-cheap ARM core like the RP2040 for teaching? Any 8 bit platform would be specialized either towards legacy support or extreme cost optimization, but not towards beginner ease of use ...
- HeyLaughingBoy 4y ago
  As someone working in industry, I really have to wonder at the reason for teaching assembly to beginners while the rest of us are trying to move up the abstraction ladder. Care to expound on why you're doing this?
  - ChuckNorris89 4y ago
    Debugging embedded software or even low level software or examining malware is much better at assembly level.
    - HeyLaughingBoy 4y ago
      I see. I don't know much about malware, but I do know a bit about embedded programming and it's been a solid 20 years since assembly has helped me to debug something.
- pclmulqdq 4y ago
  That is initially what RISC-V was for - it was born out of a teaching ISA that was easy to program and easy to implement in hardware.
pmarin 4y ago
HN is a news site, mature, battle proven solutions are not things people are hyped about.

throwaway81523 4y ago

RISC is a 32 or 64 bit arch. There was some discussion of a 16 bit version but it didn't get traction. 8 bits wouldn't really work: who wants an 8 bit cpu with 32 bit wide instructions? From a software perspective I could see some attraction to new 8-bit architectures, but in market terms it is legacy space by now, it seems to me.

Findecanor 4y ago

That AVR has 8-bit registers isn't much of a benefit today. While it might make the AVR's core small, it requires more instructions to operate on 16-bit or 32-bit values — which a lot of code has to. For instance, an "int" in AVR C is 16 bits and because C does "integer promotion", it requires 16-bit semantics even when both operands are char. Despite having wider registers, I believe RISC-V cores could be made quite small too because of how lean its ISA is. As a hobbyist, I use AVR mostly because it is 5V-capable and electrically robust, so it can interface with vintage peripherals without requiring signal-level converters or additional ESD protection. It would be nice to see more competition in this space, for sure.

gsliepen 4y ago
While the C standard does say that integer promotion happens, if the result is being cast back to char again, a C compiler will see that it doesn't need to operate on 16 bits and is allowed to optimize the result back to 8 bit operations. See for example: https://godbolt.org/z/zM8reeqrc https://godbolt.org/z/zM8reeqrc
hajile 4y ago
I feel like 16-bit MCs aren't popular because they aren't popular. They offer a straight-up 2x performance increase in most applications and something like a 4-10x performance increase with 32-bit numbers (not to mention the space savings from fewer instructions). Despite this, the 16-bit MCs all seem to be rather niche. I'd love for an open RISC-V variant that could fill this gap and allow sourcing of the same ISA from multiple companies.

PaulHoule 4y ago

I dunno. AVR-8 is basically the last 8 bit CPU so it is much better than the CPUs we remember from the 1980s like the Z80, 6502, 6809, in most respects except RAM size. 32 registers is a lot! It also takes advantage of the Harvard architecture and has none of this pipelining and cache BS, most instructions take a cycle so if it runs at 20MHz it is basically running at 20 MIPS. Assembly language is beautiful and thinking about writing C for it makes me want to cry. The one issue is that it has no upgrade path to anything more powerful so if you want something better it is going to be ARM or ESP32 so you might just keep writing portable C.

deleted 4y ago

[deleted]

phendrenad2 4y ago

Why do you want that? What do you think that would look like? What about it appeals to you? Specifically?