3 ms·

Example: The Commodore 128 (or the Plus/4 works too). The C128 had a more powerful CPU capable of 16-bit work, accessing more RAM, faster Disk access etc. But i

by leeter 6y ago

Example: The Commodore 128 (or the Plus/4 works too). The C128 had a more powerful CPU capable of 16-bit work, accessing more RAM, faster Disk access etc. But in general it was rarely targeted. Why? Because developers were looking for the widest degree of compatibility and that meant restricting themselves to the minimal possible subset of compatibility between the C128 and the C64. This meant that by and large the 128KB of ram went unused as most applications ran in C64 mode. The same applies here: the more extensions and things you pile on... the less likely they are to get used unless they are de-facto mandatory. Even today you can see games getting released that won't touch AVX instructions on both Intel and AMD because of compatibility reasons. Valve provides data to developers on penetration of various ISA extensions via the hardware survey ( https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam#cat13 https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw... ) but for RISC-V there is no way to do the same. So most utility writers will be highly constrained in what they will use in terms of expected extension use, that will have significant harms in terms of performance. Alternatively it requires recompiling for every single different target, which is also likely. In essence: you need a good baseline of compatibility for people to expect to use. It makes moving software easier between targets. A piece of software might certify for example on R64GC but not on R32IF because the double precision emulation might not work as expected or the lack of carry could be an issue etc.

simonh 6y ago
For embedded applications, which are RISC-V’s bread and butter, the hardware and software are designed hand in glove. Eg if you are designing a custom RISC-V chip for a media encoding system you will want extensions for that application, and make use of those in your development tool chain. The software for your Hardware, or at least the performance and functionality critical part, is often only targeted at your hardware, not any arbitrary RISC-V system.
devit 6y ago
This is just a tooling problem that can be solved trivially by having release builds build multiple binaries by default, for all the major extension profiles.
- leeter 6y ago
  You completely missed the point, multiple release builds doesn't actually fix the problem of emulation not having the same behavior or timing. That has a big impact on software cert for purpose and could completely torpedo an entire project where a dev team works on a GC profile because actual hardware doesn't exist yet and is supposed to release on an I profile. There is no substitute for actual hardware.

by leeter 6y ago

simonh 6y ago

For embedded applications, which are RISC-V’s bread and butter, the hardware and software are designed hand in glove. Eg if you are designing a custom RISC-V chip for a media encoding system you will want extensions for that application, and make use of those in your development tool chain. The software for your Hardware, or at least the performance and functionality critical part, is often only targeted at your hardware, not any arbitrary RISC-V system.

devit 6y ago

This is just a tooling problem that can be solved trivially by having release builds build multiple binaries by default, for all the major extension profiles.

leeter 6y ago
You completely missed the point, multiple release builds doesn't actually fix the problem of emulation not having the same behavior or timing. That has a big impact on software cert for purpose and could completely torpedo an entire project where a dev team works on a GC profile because actual hardware doesn't exist yet and is supposed to release on an I profile. There is no substitute for actual hardware.