2 ms·

I've only coded for ARM. On those devices, the toolchains etc handle the code logic, and each ARM device will have its own peripherals. Working at the MCU-regi

I've only coded for ARM. On those devices, the toolchains etc handle the code logic, and each ARM device will have its own peripherals. Working at the MCU-register level and higher, is there any difference in RISC-V? Or does it only matter if writing compilers and toolchains? Maybe the way you handle interrupts changes? Eg you would no longer use a cortex-m library to handle them. Maybe low power modes too, since those use ARM registers in addition to MCU-specific ones?

RobotToaster 4y ago
Most of the time it's only an issue if you're writing assembly.
Sirened 4y ago
It is fairly different from a systems programming perspective. The base instructions (I) are essentially everything you'd expect when writing any kind of regular program and it feels very normal and natural for anyone who has ever written assembly, but once you start needing fancier things like exceptions you'll see a lot of new RISCV specific design choices. This is sort of to be expected, x86 has a different exception architecture from ARMv8A. It's just different, not necessarily less capable. Odds are whatever RISCV MCUs come on the market will eventually be supported with the same SDKs you know and love, but they will have a different implementation for all the system specific functions.
P_I_Staker 4y ago
Basically, No, IMO. I do embedded systems. Most of the important differences, would be covered under the peripheral side. Assuming you move to a drastically different ARM chipset, there would be no difference. As disappointing as it may be to some people, architecture rarely winds up mattering much (although you might be able to argue that some elements that make it into the peripherals are "architectural"). At least for software developers, there will never be a reason to dig into architecture. Maybe for some stuff interrupt, or hardware exception related. I've found that the specific chipset and compiler tend to be more important for software developers working close to hardware. Even ASM code probably won't really matter, unless you plan to heavily rely on it; I would guess it could come into play if you plan on writing heavy ASM code, which I doubt you'd ever do on a modern architecture... maybe you're REALLY trying to save memory, or think you can improve CPU performance for some reason. Seems far fetched in almost every application, but I bet people out there are doing it for good reasons. Of course, there may always be little places where you end up doing stuff with ASM, but again IME they tend to be where the peripherals and architecture meet.

RobotToaster 4y ago

Most of the time it's only an issue if you're writing assembly.

Sirened 4y ago

It is fairly different from a systems programming perspective. The base instructions (I) are essentially everything you'd expect when writing any kind of regular program and it feels very normal and natural for anyone who has ever written assembly, but once you start needing fancier things like exceptions you'll see a lot of new RISCV specific design choices. This is sort of to be expected, x86 has a different exception architecture from ARMv8A. It's just different, not necessarily less capable. Odds are whatever RISCV MCUs come on the market will eventually be supported with the same SDKs you know and love, but they will have a different implementation for all the system specific functions.

P_I_Staker 4y ago

Basically, No, IMO. I do embedded systems. Most of the important differences, would be covered under the peripheral side. Assuming you move to a drastically different ARM chipset, there would be no difference. As disappointing as it may be to some people, architecture rarely winds up mattering much (although you might be able to argue that some elements that make it into the peripherals are "architectural"). At least for software developers, there will never be a reason to dig into architecture. Maybe for some stuff interrupt, or hardware exception related. I've found that the specific chipset and compiler tend to be more important for software developers working close to hardware. Even ASM code probably won't really matter, unless you plan to heavily rely on it; I would guess it could come into play if you plan on writing heavy ASM code, which I doubt you'd ever do on a modern architecture... maybe you're REALLY trying to save memory, or think you can improve CPU performance for some reason. Seems far fetched in almost every application, but I bet people out there are doing it for good reasons. Of course, there may always be little places where you end up doing stuff with ASM, but again IME they tend to be where the peripherals and architecture meet.