12 ms·

Simple Memory Model The RISC-V address space is byte addressed and little-endian. Even though most other ISAs such as x86 and ARM have se

Simple Memory Model The RISC-V address space is byte addressed and little-endian. Even though most other ISAs such as x86 and ARM have severalpotentially complex addressing modes, RISC-V only uses base+offset addressing with a 12-bit immediate to simplify load-store units. I remember reading [1] that one reason C became so popular was because it was easy to write a compiler for, not because it was easy to write a program in. Thus, compilers emerged for various platforms, making it accessible. At the opposite, stuff like Smalltalk (I may be mistaking the language) were complicated to implement and the compilers/environments were expensive, limiting the reach. Looks like the RISC-V is taking a page from this strategy book. [1] was it Gabriel's Worse Is Better essay? https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html

FullyFunctional 11y ago
That has no basis in reality. Smalltalk is to implement that one implementation fits in the Smalltalk-80 book. C got popular because it allowed low-level code to be implemented in something higher-level than assembler and moderately portably too (machines back then where as lot more dissimilar than today). It's hard to disassociate C from Unix, the former making the latter easy to port. A symbiotic relationship. It's important to remember C was designed for the processors of the time, whereas processors of today (RISC-V included) are arguebly primarily machines to run C. C has brought a lot of good but also a lot of bad that we are still dealing with: unchecked integer overflows, buffer under- and overflow, and more general memory corruption. No ISA since the SPARC even tries to offer support for non-C semantics.
- nickpsecurity 11y ago
  " C has brought a lot of good" I've seen no evidence that C brought us anything good. Anything I can do with C I can do with a Modula-2-like language with better safety and compiler robustness. If a check is a problem, I can disable it but it's there by default. Nonetheless, I'll look into any benefits you think C brought us that alternatives wouldn't have done.
  - mwfunk 11y ago
    The alternative to C for systems programming in the '70s was not Modula-2 or anything like it, the only realistic alternative for most production systems was writing your kernel code in assembly. C allowed the industry to finally stop defaulting to assembly for systems programming. That was a very good thing, regardless of how old and inappropriate C might be for such purposes nowadays. The comment you were responding to reads to me like someone providing historical context, not an expression of an ideal.
    - nickpsecurity 11y ago
      "The alternative to C for systems programming in the '70s was not Modula-2 or anything like it" The main alternatives were ALGOL60, ALGOL68, and Pascal. They were each designed by people who knew what they were doing in balancing many goals. They, esp ALGOLS, achieved good chunk of most. A subset and/or modification of one with gradual progression for improved hardware would've led to better results than C with same amount of labor invested. On low end, Pascal ended up being ported to systems from 8-bitters to mainframes. On high end, Burroughs implemented their mainframe OS in an ALGOL with hardware that enforced its safety for arrays, stacks, and function calls. In the 80's, things like Modula-2, Concurrent Pascal, Oberon, and Ada showed up. I'll understand if they avoided Ada given constraints at the time but the others were safer than C and quite efficient. More importantly, their authors could've used your argument back then as most people were doing but decided to build on prior work with better design. They got better results out of it, too, with many doing a lot of reliable code with very little manpower. Hansen topped it off by implementing a barebones, Wirth-like language and system called Edison on the same PDP that C was born on. "The comment you were responding to reads to me like someone providing historical context, not an expression of an ideal." The historical context in a related comment was wrong, though. It almost always is with C because people don't know it's true history. Revisionism took over. The power that revision has in locking in people to C is why I always counter it with actual evidence from the inventors of the concepts. Two quick questions to illustrate why I do that and test if it's sensible: 1. When hearing "the programmer is in control," did you think that philosophy was invented by Thompson for C or it was stolen without early credit from BCPL along with its other foundations? 2. Did you know that those were not designed or validated as a good language at all? And that they were grudgingly accepted just to get CPL, an ALGOL60 variant, to compile on crappy hardware whose problems no longer exist by chopping off most important attributes? If you knew 1 and 2, would you still think C was a "well-designed" language for systems programming? Or a failed implementation of ALGOL60 whose designers were too limited by hardware? If No 1, we should emulate the heck out of C. If No 2, we should emulate ALGOL60-like language that balances readability, efficiency, safety, and programming in the large. Btw, all the modern languages people think are productive and safer lean more toward ALGOL more than C albeit sometimes using C-like syntax for uptake. Might be corroboration of what I'm saying.
- bogomipz 11y ago
  What non-C semantics did SPARC chips offer? I wasn't aware of that.
  - FullyFunctional 11y ago
    Tagged add, optionally with overflow trapping, see https://en.wikipedia.org/wiki/SPARC https://en.wikipedia.org/wiki/SPARC This was inspired by Smalltalk on a RISC and added explicitly for Lisp and Smalltalk. Also in support of this, trapping on unaligned loads.
    - bogomipz 11y ago
      Unaligned loads? Can you elaborate? You mean not along a 4 byte boundary?
      - FullyFunctional 11y ago
        Right. The idea being that the bottom two bits of words are tag bits. tadd dictactes that they have to be 0 for integers which means pointers are non-zero in their tags. Let's say the pointer tag is 1. That means to load a word from an object will have to compensate, eg. car: ld r2, [r3-1] ret nop If it happens that r3 _wasn't_ an object pointer, that load above would not be word aligned and thus trap. In other words, the hardware does the tag checking for you. (As an aside, the 486 introduced the option for making unaligned access trap, but AFAIK, no one has ever used it because you'd have to fix all the alignment assumptions in library code).
        wolf550e 11y ago
        But unaligned load is very important to a lot of code like LZ compression.
        bogomipz 11y ago
        Thanks for the explanation.
      - 11y ago
- pjmlp 11y ago
  > C got popular because it allowed low-level code to be implemented in something higher-level than assembler and moderately portably too (machines back then where as lot more dissimilar than today). It's hard to disassociate C from Unix, the former making the latter easy to port. A symbiotic relationship. You mean like Burroughs was doing with Extended Algol in 1961 for its Burroughs B5500 system, implemented with zero lines of Assembly, while offering all the features for memory safety that C designers deemed too hard to implement? Archeology of systems programming languages is great to dismitify the magic aura C seems to have gained in the last 20 years with the raise of FOSS.
  - AnimalMuppet 11y ago
    "Extended Algol"? So, not Algol, then. Algol with the parts that would be in assembly language turned into libraries? And FullyFunctional's point was largely about portability. So, if Burroughts took that OS and tried to port it to, say, a PDP-11, how well do you think that would have worked?
    - pjmlp 11y ago
      Just like it is impossible to have an ANSI C library without Assembly or language extensions. Extended Algol had what we would call intrisics nowadays. PDP-11 was more powerful than Burroughs systems.
      - AnimalMuppet 11y ago
        > Just like it is impossible to have an ANSI C library without Assembly or language extensions. Extended Algol had what we would call intrisics nowadays. Sure. It makes your "zero lines of assembly" claim somewhat less impressive, though...
        pjmlp 11y ago
        Intrinsics aren't the same as Assembly. Intrinsics semantics can be validated by the compiler. https://en.wikipedia.org/wiki/Burroughs_large_systems#ESPOL_and_NEWP https://en.wikipedia.org/wiki/Burroughs_large_systems#ESPOL_... "In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi-level protection mechanism." "NEWP programs that contain unsafe constructs are initially non-executable. The security administrator of a system is able to "bless" such programs and make them executable, but normal users are not able to do this." "NEWP has a number of facilities to enable large-scale software projects, such as the operating system, including named interfaces (functions and data), groups of interfaces, modules, and super-modules. Modules group data and functions together, allowing easy access to the data as global within the module. Interfaces allow a module to import and export functions and data. Super-modules allow modules to be grouped." Sounds familiar? Rust like safety in 1961, but lets praise C instead.
- hga 11y ago
  unchecked integer overflows This is my one big beef with the RISC-V ISA, after I went over it with a fine toothed comb, otherwise it's brilliant to my untutored eyes, and the ISA doc, a paper I read about the same time about how difficult it was to make ISAs super fast, etc. helped explain why, e.g. the VAX ISA took so long to make faster, and was probably doomed, while Intel got lucky? with x86. Anyway, the large integer math e.g. crypto people are not happy about it, the lack of support for anything other than being able to check for divide by zero means their code will be slow compared to older ISAs that support it. And their justification in the ISA doc is that the most popular languages nowadays don't check for this, which is not the sort of thing I want to see for an ISA that's billing itself as a big thing for the future. I very much got Worse Is Better/the New Jersey vibes from this.... Although this discussion a couple of weeks ago implies it's getting some consideration: https://groups.google.com/a/groups.riscv.org/forum/#!searchin/isa-dev/overflow/isa-dev/7VYmVR47o1Q/856mYZB7AgAJ https://groups.google.com/a/groups.riscv.org/forum/#!searchi...
  - FullyFunctional 11y ago
    Intel didn't get "lucky". Going superscalar (and OoO) with CISC ISA's like the VAX, IBM/360, x86, ... obviously isn't impossible (as illustracted by IBM's zNext and Intel's everything), but it's VERY difficult (thus hard to design and verify => time to market risks) and expensive (it takes a lot of logic and more pipeline stages). An ISA like RISC-V tries to avoid as much as _practical_ of these obstackles, thus making it easier & cheaper for implementations to be fast. This part is straight out of the DEC Alpha playbook. Re. large integers: the RISC-V 2.0 (non-priv) ISA is frozen solid so any change would have to be an extension. I've been gently pushing for the mythical vector extension to be at least friendly to large integers.
nickpsecurity 11y ago
Other commenter's claim is inaccurate. I have a detailed history, with references, of how C became what it was: http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG That its predecessor compiled on an EDSAC, it compiled on a PDP-11, and was the language of UNIX (its killer app) was why it spread everywhere. Network/legacy effects took over from there. There were languages like Modula-2 that were safer, efficient, easy to implement, and still close to the metal. Such languages kept being ignored and mostly are to this day for system programming. They even ignore the ones that are basically C with enhanced safety (eg Cyclone, Popcorn). It's all social and economic reasons justifying C both at its creation, during its spread, and for its continuing use. The technical case against such a language has always been there and field-proven many times.
- scythe 11y ago
  Have you ever actually tried to write code in Modula-2? Has there ever been an efficient, portable implementation of Cyclone or Popcorn? Does anyone seriously consider either to be easy to implement? And, if you just randomly picked three examples, why are they all bad? What does that mean about the other examples, statistically?
  - nickpsecurity 11y ago
    "Have you ever actually tried to write code in Modula-2?" Three people wrote a consistent, safer platform in it from OS to compiler to apps in 2 years. Amateurs repeated did stuff like that with it and its successors like Oberon for another decade or two. How long did the first UNIX take to get written and reliable in C? "Has there ever been an efficient, portable implementation of Cyclone or Popcorn? " I could've said that about C in its early years given it wasn't intended to be portable. Turns out that stripping almost every good feature out of a language until it's a few primitives makes it portable by default. "And, if you just randomly picked three examples, why are they all bad? What does that mean about the other examples, statistically?" It means that, statistically, the other examples will have most of C's efficiency with little to none of its weaknesses. People using them will get hacked or loose work less. Like with all safe, systems languages that people turned down over C. Least important, it means I picked the examples closest to C in features and efficiency because C developers' culture rejects anything too different. That includes better options I often reference. Why is that bad for their ability to produce robust programs? And what does that mean about C developers statistically?

FullyFunctional 11y ago

That has no basis in reality. Smalltalk is to implement that one implementation fits in the Smalltalk-80 book. C got popular because it allowed low-level code to be implemented in something higher-level than assembler and moderately portably too (machines back then where as lot more dissimilar than today). It's hard to disassociate C from Unix, the former making the latter easy to port. A symbiotic relationship. It's important to remember C was designed for the processors of the time, whereas processors of today (RISC-V included) are arguebly primarily machines to run C. C has brought a lot of good but also a lot of bad that we are still dealing with: unchecked integer overflows, buffer under- and overflow, and more general memory corruption. No ISA since the SPARC even tries to offer support for non-C semantics.

nickpsecurity 11y ago
" C has brought a lot of good" I've seen no evidence that C brought us anything good. Anything I can do with C I can do with a Modula-2-like language with better safety and compiler robustness. If a check is a problem, I can disable it but it's there by default. Nonetheless, I'll look into any benefits you think C brought us that alternatives wouldn't have done.
- mwfunk 11y ago
  The alternative to C for systems programming in the '70s was not Modula-2 or anything like it, the only realistic alternative for most production systems was writing your kernel code in assembly. C allowed the industry to finally stop defaulting to assembly for systems programming. That was a very good thing, regardless of how old and inappropriate C might be for such purposes nowadays. The comment you were responding to reads to me like someone providing historical context, not an expression of an ideal.
  - nickpsecurity 11y ago
    "The alternative to C for systems programming in the '70s was not Modula-2 or anything like it" The main alternatives were ALGOL60, ALGOL68, and Pascal. They were each designed by people who knew what they were doing in balancing many goals. They, esp ALGOLS, achieved good chunk of most. A subset and/or modification of one with gradual progression for improved hardware would've led to better results than C with same amount of labor invested. On low end, Pascal ended up being ported to systems from 8-bitters to mainframes. On high end, Burroughs implemented their mainframe OS in an ALGOL with hardware that enforced its safety for arrays, stacks, and function calls. In the 80's, things like Modula-2, Concurrent Pascal, Oberon, and Ada showed up. I'll understand if they avoided Ada given constraints at the time but the others were safer than C and quite efficient. More importantly, their authors could've used your argument back then as most people were doing but decided to build on prior work with better design. They got better results out of it, too, with many doing a lot of reliable code with very little manpower. Hansen topped it off by implementing a barebones, Wirth-like language and system called Edison on the same PDP that C was born on. "The comment you were responding to reads to me like someone providing historical context, not an expression of an ideal." The historical context in a related comment was wrong, though. It almost always is with C because people don't know it's true history. Revisionism took over. The power that revision has in locking in people to C is why I always counter it with actual evidence from the inventors of the concepts. Two quick questions to illustrate why I do that and test if it's sensible: 1. When hearing "the programmer is in control," did you think that philosophy was invented by Thompson for C or it was stolen without early credit from BCPL along with its other foundations? 2. Did you know that those were not designed or validated as a good language at all? And that they were grudgingly accepted just to get CPL, an ALGOL60 variant, to compile on crappy hardware whose problems no longer exist by chopping off most important attributes? If you knew 1 and 2, would you still think C was a "well-designed" language for systems programming? Or a failed implementation of ALGOL60 whose designers were too limited by hardware? If No 1, we should emulate the heck out of C. If No 2, we should emulate ALGOL60-like language that balances readability, efficiency, safety, and programming in the large. Btw, all the modern languages people think are productive and safer lean more toward ALGOL more than C albeit sometimes using C-like syntax for uptake. Might be corroboration of what I'm saying.
bogomipz 11y ago
What non-C semantics did SPARC chips offer? I wasn't aware of that.
- FullyFunctional 11y ago
  Tagged add, optionally with overflow trapping, see https://en.wikipedia.org/wiki/SPARC https://en.wikipedia.org/wiki/SPARC This was inspired by Smalltalk on a RISC and added explicitly for Lisp and Smalltalk. Also in support of this, trapping on unaligned loads.
  - bogomipz 11y ago
    Unaligned loads? Can you elaborate? You mean not along a 4 byte boundary?
    - FullyFunctional 11y ago
      Right. The idea being that the bottom two bits of words are tag bits. tadd dictactes that they have to be 0 for integers which means pointers are non-zero in their tags. Let's say the pointer tag is 1. That means to load a word from an object will have to compensate, eg. car: ld r2, [r3-1] ret nop If it happens that r3 _wasn't_ an object pointer, that load above would not be word aligned and thus trap. In other words, the hardware does the tag checking for you. (As an aside, the 486 introduced the option for making unaligned access trap, but AFAIK, no one has ever used it because you'd have to fix all the alignment assumptions in library code).
      - wolf550e 11y ago
        But unaligned load is very important to a lot of code like LZ compression.
      - bogomipz 11y ago
        Thanks for the explanation.
    - 11y ago
pjmlp 11y ago
> C got popular because it allowed low-level code to be implemented in something higher-level than assembler and moderately portably too (machines back then where as lot more dissimilar than today). It's hard to disassociate C from Unix, the former making the latter easy to port. A symbiotic relationship. You mean like Burroughs was doing with Extended Algol in 1961 for its Burroughs B5500 system, implemented with zero lines of Assembly, while offering all the features for memory safety that C designers deemed too hard to implement? Archeology of systems programming languages is great to dismitify the magic aura C seems to have gained in the last 20 years with the raise of FOSS.
- AnimalMuppet 11y ago
  "Extended Algol"? So, not Algol, then. Algol with the parts that would be in assembly language turned into libraries? And FullyFunctional's point was largely about portability. So, if Burroughts took that OS and tried to port it to, say, a PDP-11, how well do you think that would have worked?
  - pjmlp 11y ago
    Just like it is impossible to have an ANSI C library without Assembly or language extensions. Extended Algol had what we would call intrisics nowadays. PDP-11 was more powerful than Burroughs systems.
    - AnimalMuppet 11y ago
      > Just like it is impossible to have an ANSI C library without Assembly or language extensions. Extended Algol had what we would call intrisics nowadays. Sure. It makes your "zero lines of assembly" claim somewhat less impressive, though...
      - pjmlp 11y ago
        Intrinsics aren't the same as Assembly. Intrinsics semantics can be validated by the compiler. https://en.wikipedia.org/wiki/Burroughs_large_systems#ESPOL_and_NEWP https://en.wikipedia.org/wiki/Burroughs_large_systems#ESPOL_... "In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi-level protection mechanism." "NEWP programs that contain unsafe constructs are initially non-executable. The security administrator of a system is able to "bless" such programs and make them executable, but normal users are not able to do this." "NEWP has a number of facilities to enable large-scale software projects, such as the operating system, including named interfaces (functions and data), groups of interfaces, modules, and super-modules. Modules group data and functions together, allowing easy access to the data as global within the module. Interfaces allow a module to import and export functions and data. Super-modules allow modules to be grouped." Sounds familiar? Rust like safety in 1961, but lets praise C instead.
hga 11y ago
unchecked integer overflows This is my one big beef with the RISC-V ISA, after I went over it with a fine toothed comb, otherwise it's brilliant to my untutored eyes, and the ISA doc, a paper I read about the same time about how difficult it was to make ISAs super fast, etc. helped explain why, e.g. the VAX ISA took so long to make faster, and was probably doomed, while Intel got lucky? with x86. Anyway, the large integer math e.g. crypto people are not happy about it, the lack of support for anything other than being able to check for divide by zero means their code will be slow compared to older ISAs that support it. And their justification in the ISA doc is that the most popular languages nowadays don't check for this, which is not the sort of thing I want to see for an ISA that's billing itself as a big thing for the future. I very much got Worse Is Better/the New Jersey vibes from this.... Although this discussion a couple of weeks ago implies it's getting some consideration: https://groups.google.com/a/groups.riscv.org/forum/#!searchin/isa-dev/overflow/isa-dev/7VYmVR47o1Q/856mYZB7AgAJ https://groups.google.com/a/groups.riscv.org/forum/#!searchi...
- FullyFunctional 11y ago
  Intel didn't get "lucky". Going superscalar (and OoO) with CISC ISA's like the VAX, IBM/360, x86, ... obviously isn't impossible (as illustracted by IBM's zNext and Intel's everything), but it's VERY difficult (thus hard to design and verify => time to market risks) and expensive (it takes a lot of logic and more pipeline stages). An ISA like RISC-V tries to avoid as much as _practical_ of these obstackles, thus making it easier & cheaper for implementations to be fast. This part is straight out of the DEC Alpha playbook. Re. large integers: the RISC-V 2.0 (non-priv) ISA is frozen solid so any change would have to be an extension. I've been gently pushing for the mythical vector extension to be at least friendly to large integers.

nickpsecurity 11y ago

Other commenter's claim is inaccurate. I have a detailed history, with references, of how C became what it was: http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG That its predecessor compiled on an EDSAC, it compiled on a PDP-11, and was the language of UNIX (its killer app) was why it spread everywhere. Network/legacy effects took over from there. There were languages like Modula-2 that were safer, efficient, easy to implement, and still close to the metal. Such languages kept being ignored and mostly are to this day for system programming. They even ignore the ones that are basically C with enhanced safety (eg Cyclone, Popcorn). It's all social and economic reasons justifying C both at its creation, during its spread, and for its continuing use. The technical case against such a language has always been there and field-proven many times.

scythe 11y ago
Have you ever actually tried to write code in Modula-2? Has there ever been an efficient, portable implementation of Cyclone or Popcorn? Does anyone seriously consider either to be easy to implement? And, if you just randomly picked three examples, why are they all bad? What does that mean about the other examples, statistically?
- nickpsecurity 11y ago
  "Have you ever actually tried to write code in Modula-2?" Three people wrote a consistent, safer platform in it from OS to compiler to apps in 2 years. Amateurs repeated did stuff like that with it and its successors like Oberon for another decade or two. How long did the first UNIX take to get written and reliable in C? "Has there ever been an efficient, portable implementation of Cyclone or Popcorn? " I could've said that about C in its early years given it wasn't intended to be portable. Turns out that stripping almost every good feature out of a language until it's a few primitives makes it portable by default. "And, if you just randomly picked three examples, why are they all bad? What does that mean about the other examples, statistically?" It means that, statistically, the other examples will have most of C's efficiency with little to none of its weaknesses. People using them will get hacked or loose work less. Like with all safe, systems languages that people turned down over C. Least important, it means I picked the examples closest to C in features and efficiency because C developers' culture rejects anything too different. That includes better options I often reference. Why is that bad for their ability to produce robust programs? And what does that mean about C developers statistically?