3 ms·

Yes, assembly is more flexible than my favorite higher level language. Because if you have access to assembly, you can implement the whatever higher level lang

Yes, assembly is more flexible than my favorite higher level language. Because if you have access to assembly, you can implement the whatever higher level language or semantics you want. Whereas if you only have a higher level language, you have to work with/around the abstractions baked into it. For realtime applications it's better to at least have access to a low-level, less overhead API.

kazinator 11y ago
That is true. For example, in assembly we can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention. We cannot do that in C. That's because there are areas of the program state that are "off limits", and the compiler generates "GC ignorant" code.
- bsurmanski 11y ago
  do you mind elaborating on this? What would be off limits, and what in assembly would allow a garbage collector free of false retention vs C?
  - kazinator 11y ago
    What in assembly would allow freedom from false retention is that we know exactly what is in every register and memory location (because we put it there). We know where the GC has to look for root references and where it doesn't have to look. In C, if we have a pointer p which is the last reference to some object, and is not used any more, and add the line "p = NULL", hoping to drop a reference so the object can be reclaimed, there is no guarantee that the compiler actually generates the code which does the assignment. Since the variable has no next use, and the compiler doesn't know anything about garbage collection, the assignment looks like wasteful, dead code that should be optimized away. Even if the scope finishes executing, the compiler can leave behind a memory location which still references the object. Here is something else, not related to GC. In assembly language, we can make ourselves a calling convention for variadic functions which know how many arguments they have. As we build up the higher level language, it will have nicely featured variadic functions. In C, we are stuck with <stdarg.h> which doesn't have a mechanism for the callee to know where the arguments end. The language has no flexibility to add this --- without resorting to approaches which will basically involve assembly language.
- aidenn0 11y ago
  In C you can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention. You can do it portably if you just don't store objects on the C stack, and you can do it non-portably if you do so.
  - kazinator 11y ago
    > In C you can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention. If so, you will be the first; I look forward to the "Show HN:" when it's done. > You can do it portably if you just don't store objects on the C stack, Sure, for example, you can do it portably in C if you write a complete emulator for an 80386, and then use that to run an assembly language program. That program isn't a utility for your C code; it's not extending the host C with a garbage collector or whatever else. If you do not store object references on the stack, your use of C is severely crippled to the point that it's not really C any more. For one thing, C function arguments are on the stack (or, more abstractly, "automatic storage"), so say goodbye to conventional use of C argument passing: the backbone of most normal C programming. That garbage collector isn't for C. C has automatic storage, and a proper garbage collector has to traverse it. > and you can do it non-portably if you do so. Sure, if non-portably means going as far as forking a specific C compiler with your custom hacks, and requiring that C compiler, or else living with the imprecision and taking a whack-a-mole approach to plugging the issues as they arise.
    - aidenn0 11y ago
      Chicken scheme uses C function calls, and merely requires a contiguous stack for automatic storage (which is technically non-portable, but doesn't require forking a compiler): http://en.wikipedia.org/wiki/CHICKEN_%28Scheme_implementation%29 http://en.wikipedia.org/wiki/CHICKEN_%28Scheme_implementatio... [edit] And here is a toy scheme interpreter that uses precise garbage collection to show off the Ravenbrook MPS http://www.ravenbrook.com/project/mps/master/manual/html/guide/lang.html#the-scheme-interpreter http://www.ravenbrook.com/project/mps/master/manual/html/gui...

kazinator 11y ago

That is true. For example, in assembly we can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention. We cannot do that in C. That's because there are areas of the program state that are "off limits", and the compiler generates "GC ignorant" code.

bsurmanski 11y ago
do you mind elaborating on this? What would be off limits, and what in assembly would allow a garbage collector free of false retention vs C?
- kazinator 11y ago
  What in assembly would allow freedom from false retention is that we know exactly what is in every register and memory location (because we put it there). We know where the GC has to look for root references and where it doesn't have to look. In C, if we have a pointer p which is the last reference to some object, and is not used any more, and add the line "p = NULL", hoping to drop a reference so the object can be reclaimed, there is no guarantee that the compiler actually generates the code which does the assignment. Since the variable has no next use, and the compiler doesn't know anything about garbage collection, the assignment looks like wasteful, dead code that should be optimized away. Even if the scope finishes executing, the compiler can leave behind a memory location which still references the object. Here is something else, not related to GC. In assembly language, we can make ourselves a calling convention for variadic functions which know how many arguments they have. As we build up the higher level language, it will have nicely featured variadic functions. In C, we are stuck with <stdarg.h> which doesn't have a mechanism for the callee to know where the arguments end. The language has no flexibility to add this --- without resorting to approaches which will basically involve assembly language.
aidenn0 11y ago
In C you can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention. You can do it portably if you just don't store objects on the C stack, and you can do it non-portably if you do so.
- kazinator 11y ago
  > In C you can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention. If so, you will be the first; I look forward to the "Show HN:" when it's done. > You can do it portably if you just don't store objects on the C stack, Sure, for example, you can do it portably in C if you write a complete emulator for an 80386, and then use that to run an assembly language program. That program isn't a utility for your C code; it's not extending the host C with a garbage collector or whatever else. If you do not store object references on the stack, your use of C is severely crippled to the point that it's not really C any more. For one thing, C function arguments are on the stack (or, more abstractly, "automatic storage"), so say goodbye to conventional use of C argument passing: the backbone of most normal C programming. That garbage collector isn't for C. C has automatic storage, and a proper garbage collector has to traverse it. > and you can do it non-portably if you do so. Sure, if non-portably means going as far as forking a specific C compiler with your custom hacks, and requiring that C compiler, or else living with the imprecision and taking a whack-a-mole approach to plugging the issues as they arise.
  - aidenn0 11y ago
    Chicken scheme uses C function calls, and merely requires a contiguous stack for automatic storage (which is technically non-portable, but doesn't require forking a compiler): http://en.wikipedia.org/wiki/CHICKEN_%28Scheme_implementation%29 http://en.wikipedia.org/wiki/CHICKEN_%28Scheme_implementatio... [edit] And here is a toy scheme interpreter that uses precise garbage collection to show off the Ravenbrook MPS http://www.ravenbrook.com/project/mps/master/manual/html/guide/lang.html#the-scheme-interpreter http://www.ravenbrook.com/project/mps/master/manual/html/gui...