5 ms·

> This is the first step. No, one of many steps already taken. > I would have prefered a 64bits core Sounds like you're not in the target market. > because

> This is the first step. No, one of many steps already taken. > I would have prefered a 64bits core Sounds like you're not in the target market. > because once I write 64bits RISC-V assembly code paths, I could really re-use them on desktop/server/embedded. Not really. There's not much overlap between "desktop/server" (a 64 bit only affair) and "embedded" (mostly 32 bit cores). Not to mention that apart from 32<->64 bit, the programming environment tends to be very different between these: system complexity, boot procedure, how to interact with outside world - just to name a few. In short: pick target device(s), code for that. Want code to move easily between different types of devices? Then code in something other than assembly.

einpoklum 3y ago
Agree generally, but not with this statement: > There's not much overlap between "desktop/server" (a 64 bit only affair) and "embedded" (mostly 32 bit cores). Most code compiles nicely targeting either 32-bit or 64-bit platforms. Certainly, there's quite a lot of code that's architecture-specific, and some code that's useful in general in embedded environments and less in full-fledged PCs/servers, but - the symmetric difference not being empty doesn't imply the overlap is empty.
- braho 3y ago
  Note that they were talking about _assembly_ code paths and parent explicitly mentioned using anything else then assembly would give you more portability.
  - brucehoult 3y ago
    It's easy to write RISC-V assembly language that works on both 32 bit and 64 bit, using a handful of simple macros.
    - sylware 3y ago
      This is what I told a commenter. But I don't even want to deal with those macros, just a nearly zero straight copy/paste. The preprocessor scares me, because once some devs starts to use it, many will want to push to max its usage everywhere and in the end, your code path is actually tied to the preprocessor, and sometimes with actually a whole new assembly language defined with the preprocessor, and if it is complex, the "exit cost" from it will sky rocket. For instance fasmg has an extremely powerful macro preprocessor, because this preprocessor is actually what's used to write assemblers. Due to the tendency of devs to maximize the usage of their SDK tools, some code paths actually end up with little assembly and a lot of macros! Then you must embrace that new language as a whole, like the opacity of the "object oriented model" of some big c++ projects BEFORE actually being able to do anything real for this very project. Personnally, I use a "normal" C preprocessor to define a minimal layer for a intel syntax assembler, which allows me to assemble with fasmg, gas and nasm/yasm. And I am very careful at assembling all the time with all assemblers. I do the same with C using cproc/qbe, tinycc, gcc, and I plan to add simple-cc/qbe. I actually do compile up to 1.1 times... the 0.1 accounting for cproc/qbe + tinycc and gcc get the rest.
sylware 3y ago
This is a first step: as far as I know its an explicit first for AMD (they may have had private RISC-V cores though). There is so much code actually shared, or with very little variations, that it is a big win for code re-use to stick to 64bits, even for "embedded".
- RetroTechie 3y ago
  > There is so much code actually shared, or with very little variations, that it is a big win for code re-use to stick to 64bits, even for "embedded". "Embedded" is a broad concept. Sure there's applications where the size/cost penalty of a 64 bit core is insignificant. Or you want it anyway to use software designed for it (like common Linux distributions). But there's also a loooottt of applications where you really want the simplest, lowest cost, lowest power cores available: solar powered mesh sensor networks, RFID tags, tiny controllers in eg. an USB peripheral, AA powered childrens toys, that clock in your microwave, etc, etc, etc. Often referred to as "deeply embedded". For such uses, 32 bit cores like ARM Cortex-M series or RV32I (or even -E) rule. To the point that even ancient 8/16 bit architectures like 8051 are still used. It would be dumb to put a 64b core there just to 're-use code paths'. C compilers are a thing, and assembly programmers know how to handle different ISAs.
  - sylware 3y ago
    This is exactly what I do not want to do: use a C compiler. And even though 32bits RISC-V assembly is very close to 64bits RISC-V assembly, I don't want to rely too much on an assembler macro pre-processor to do the switch. And yes "embedded" is nowdays quite "broad". Of course, for the "very" "embedded" even a 32bits RISC-V core is overkill, a broadly available 8bits processor will be enough if you really are going for the bucks, which I am not going for. In my world, I would have 2 targets, a mini domestic server (email, maybe a few small web servers, more?). A linux based OS would be the start, but I guess it would end up more like a custom patchwork of code paths from various projects than vanilla "linux". There are already many 64bits RISC-V SOC with existing boards for that. Then a mini-board with a SOC with at its center a 64bits RISC-V MCU for a DYO custom keyboard, which would require a USB device hardware block, flash memory, timer, a lot of GPIOs, etc. There are already some options here too, but a tad too overkill (often with "AI"). Ofc, if I could get a RISC-V powerful workstation on which I could play AAA 3D games...

einpoklum 3y ago

Agree generally, but not with this statement: > There's not much overlap between "desktop/server" (a 64 bit only affair) and "embedded" (mostly 32 bit cores). Most code compiles nicely targeting either 32-bit or 64-bit platforms. Certainly, there's quite a lot of code that's architecture-specific, and some code that's useful in general in embedded environments and less in full-fledged PCs/servers, but - the symmetric difference not being empty doesn't imply the overlap is empty.

braho 3y ago
Note that they were talking about _assembly_ code paths and parent explicitly mentioned using anything else then assembly would give you more portability.
- brucehoult 3y ago
  It's easy to write RISC-V assembly language that works on both 32 bit and 64 bit, using a handful of simple macros.
  - sylware 3y ago
    This is what I told a commenter. But I don't even want to deal with those macros, just a nearly zero straight copy/paste. The preprocessor scares me, because once some devs starts to use it, many will want to push to max its usage everywhere and in the end, your code path is actually tied to the preprocessor, and sometimes with actually a whole new assembly language defined with the preprocessor, and if it is complex, the "exit cost" from it will sky rocket. For instance fasmg has an extremely powerful macro preprocessor, because this preprocessor is actually what's used to write assemblers. Due to the tendency of devs to maximize the usage of their SDK tools, some code paths actually end up with little assembly and a lot of macros! Then you must embrace that new language as a whole, like the opacity of the "object oriented model" of some big c++ projects BEFORE actually being able to do anything real for this very project. Personnally, I use a "normal" C preprocessor to define a minimal layer for a intel syntax assembler, which allows me to assemble with fasmg, gas and nasm/yasm. And I am very careful at assembling all the time with all assemblers. I do the same with C using cproc/qbe, tinycc, gcc, and I plan to add simple-cc/qbe. I actually do compile up to 1.1 times... the 0.1 accounting for cproc/qbe + tinycc and gcc get the rest.

sylware 3y ago

This is a first step: as far as I know its an explicit first for AMD (they may have had private RISC-V cores though). There is so much code actually shared, or with very little variations, that it is a big win for code re-use to stick to 64bits, even for "embedded".

RetroTechie 3y ago
> There is so much code actually shared, or with very little variations, that it is a big win for code re-use to stick to 64bits, even for "embedded". "Embedded" is a broad concept. Sure there's applications where the size/cost penalty of a 64 bit core is insignificant. Or you want it anyway to use software designed for it (like common Linux distributions). But there's also a loooottt of applications where you really want the simplest, lowest cost, lowest power cores available: solar powered mesh sensor networks, RFID tags, tiny controllers in eg. an USB peripheral, AA powered childrens toys, that clock in your microwave, etc, etc, etc. Often referred to as "deeply embedded". For such uses, 32 bit cores like ARM Cortex-M series or RV32I (or even -E) rule. To the point that even ancient 8/16 bit architectures like 8051 are still used. It would be dumb to put a 64b core there just to 're-use code paths'. C compilers are a thing, and assembly programmers know how to handle different ISAs.
- sylware 3y ago
  This is exactly what I do not want to do: use a C compiler. And even though 32bits RISC-V assembly is very close to 64bits RISC-V assembly, I don't want to rely too much on an assembler macro pre-processor to do the switch. And yes "embedded" is nowdays quite "broad". Of course, for the "very" "embedded" even a 32bits RISC-V core is overkill, a broadly available 8bits processor will be enough if you really are going for the bucks, which I am not going for. In my world, I would have 2 targets, a mini domestic server (email, maybe a few small web servers, more?). A linux based OS would be the start, but I guess it would end up more like a custom patchwork of code paths from various projects than vanilla "linux". There are already many 64bits RISC-V SOC with existing boards for that. Then a mini-board with a SOC with at its center a 64bits RISC-V MCU for a DYO custom keyboard, which would require a USB device hardware block, flash memory, timer, a lot of GPIOs, etc. There are already some options here too, but a tad too overkill (often with "AI"). Ofc, if I could get a RISC-V powerful workstation on which I could play AAA 3D games...