5 ms·

What would it need to be a good embedded system or distributed system language?

nickpsecurity 10y ago
For embedded, I'd start with the language primitives easily producing efficient primitives of the machine, the cost (esp time/memory) of language primitives must be intuitive (ideally deterministic), be able to size/manipulate variables at the bit level, probably support pointers, have anywhere from tiny to no runtime, probably a good C FFI given existing stuff will be C-based, and ideally support inline assembly for stuff specific to MCU/CPU if not C-based. Any embedded developers want to add to or dispute anything on that list? It's recent draft of a reference I'm working on to answer this common question.
- ChuckMcM 10y ago
  I think that is a good start, I would add interrupt routines to it. Perhaps interrupt routines, arbitrary memory manipulation on a bit boundary, and tight code.
- RX14 10y ago
  > language primitives easily producing efficient primitives of the machine I think crystal already does this well, especially in release mode when llvm gets to optimise the program as a whole. This also seems like something that can be improved without any breaking changes, which is nice. > the cost (esp time/memory) of language primitives must be intuitive (ideally deterministic) I'm less sure of this, maybe having dynamic dispatch would be an issue here? I think that release optimisations would make the performance of any code pretty variable depending on what optimisations are applied. Asterite probably knows more about this than me. > be able to size/manipulate variables at the bit level Crystal supports bitwise operators for doing bit twiddling, and obviously llvm optimises that very well. As for sizing values at the bit level, unfortunately only the standard Int8, Int16, Int32, Int64 and their unsigned varieties are available for integers in crystal. There also isn't a great deal of fine control over padding and placement in structs, apart from padding on/off. This could probably be easily improved. > support pointers Crystal supports both pass-by-reference and pass-by-value structures (class and struct), and all pointer operations available in C should be easily doable in Crystal. > have anywhere from tiny to no runtime Crystal has quite a big runtime by default, but fortunately it's really easy to turn it off and import only the bits you want using --prelude=empty, which imports only the bare minimum [0]. You could then build your own standard library built without a GC, or implement a GC module (for example [1] which just uses malloc) which would allow you to reuse String, Array, hash, etc. > a good C FFI https://crystal-lang.org/docs/syntax_and_semantics/c_bindings/index.html https://crystal-lang.org/docs/syntax_and_semantics/c_binding... > support inline assembly Crystal has this too, used here: https://github.com/crystal-lang/crystal/blob/master/src/fiber.cr#L148 https://github.com/crystal-lang/crystal/blob/master/src/fibe... although this too could be improved. Overall I think Crystal has promise, and could be used for embedded programming without too much hassle, although its not a high priority of the core team. I know someone built a small kernel which just outputted "hello world" on x86 qemu. [0] https://github.com/crystal-lang/crystal/blob/master/src/empty.cr https://github.com/crystal-lang/crystal/blob/master/src/empt... [1] https://github.com/crystal-lang/crystal/blob/master/src/gc/null.cr https://github.com/crystal-lang/crystal/blob/master/src/gc/n...
  - nickpsecurity 10y ago
    A Ruby-like language that's already that close to embedded needs? Wow, Im impressed. Might toy with it sometime in the future.
  - deleted 10y ago
    [deleted]

For embedded, I'd start with the language primitives easily producing efficient primitives of the machine, the cost (esp time/memory) of language primitives must be intuitive (ideally deterministic), be able to size/manipulate variables at the bit level, probably support pointers, have anywhere from tiny to no runtime, probably a good C FFI given existing stuff will be C-based, and ideally support inline assembly for stuff specific to MCU/CPU if not C-based. Any embedded developers want to add to or dispute anything on that list? It's recent draft of a reference I'm working on to answer this common question.

ChuckMcM 10y ago
I think that is a good start, I would add interrupt routines to it. Perhaps interrupt routines, arbitrary memory manipulation on a bit boundary, and tight code.
RX14 10y ago
> language primitives easily producing efficient primitives of the machine I think crystal already does this well, especially in release mode when llvm gets to optimise the program as a whole. This also seems like something that can be improved without any breaking changes, which is nice. > the cost (esp time/memory) of language primitives must be intuitive (ideally deterministic) I'm less sure of this, maybe having dynamic dispatch would be an issue here? I think that release optimisations would make the performance of any code pretty variable depending on what optimisations are applied. Asterite probably knows more about this than me. > be able to size/manipulate variables at the bit level Crystal supports bitwise operators for doing bit twiddling, and obviously llvm optimises that very well. As for sizing values at the bit level, unfortunately only the standard Int8, Int16, Int32, Int64 and their unsigned varieties are available for integers in crystal. There also isn't a great deal of fine control over padding and placement in structs, apart from padding on/off. This could probably be easily improved. > support pointers Crystal supports both pass-by-reference and pass-by-value structures (class and struct), and all pointer operations available in C should be easily doable in Crystal. > have anywhere from tiny to no runtime Crystal has quite a big runtime by default, but fortunately it's really easy to turn it off and import only the bits you want using --prelude=empty, which imports only the bare minimum [0]. You could then build your own standard library built without a GC, or implement a GC module (for example [1] which just uses malloc) which would allow you to reuse String, Array, hash, etc. > a good C FFI https://crystal-lang.org/docs/syntax_and_semantics/c_bindings/index.html https://crystal-lang.org/docs/syntax_and_semantics/c_binding... > support inline assembly Crystal has this too, used here: https://github.com/crystal-lang/crystal/blob/master/src/fiber.cr#L148 https://github.com/crystal-lang/crystal/blob/master/src/fibe... although this too could be improved. Overall I think Crystal has promise, and could be used for embedded programming without too much hassle, although its not a high priority of the core team. I know someone built a small kernel which just outputted "hello world" on x86 qemu. [0] https://github.com/crystal-lang/crystal/blob/master/src/empty.cr https://github.com/crystal-lang/crystal/blob/master/src/empt... [1] https://github.com/crystal-lang/crystal/blob/master/src/gc/null.cr https://github.com/crystal-lang/crystal/blob/master/src/gc/n...
- nickpsecurity 10y ago
  A Ruby-like language that's already that close to embedded needs? Wow, Im impressed. Might toy with it sometime in the future.
- deleted 10y ago
  [deleted]