Hylo in Resource-Constrained Embedded

[waydan]

I really like the Hylo language and think it's offering something unique through its simpler approach to memory safety. Is love to use it in a resource-constrained embedded system, so I'm wondering how it will support a few features/use cases.

1. Deterministic Exceptions
   I can't use C++ on my platform because the exception implementation relies on dynamic memory (causing non-deterministic execution time) and RTTI (bloating the image side). P0709 explains this is due to the way exceptions are specified in the language. I prefer exceptions over something like Rust's Result<T, E> sum type because the former offers - in my naive view - higher fidelity: no need to create special optimizations for a library type and a thrown value could be converted to such a library type when necessary. Will the Hylo specification make guarantees about how exceptions are raised such that dynamic memory is not required?

2. Explicit Structure Layout
   Memory-mapped registers are usually grouped into structures. It would be nice, as in Ada if the offers, ordering, and padding of structure data members could be explicitly specified in the source file. Such a feature should be opt-in since most data types don't require this control.

3. Accessing Special Function Registers
   I wonder how memory-mapped registers could work in Hylo, since they're the poster child for non-local reasoning. The registers have static lifetime and are implicitly initialized by hardware during rest. How will that fit the MVC model; will I need unsafe statements? Will Hylo support volatile memory operations? Could I express an memory address at compile time in the source code (C++ doesn't allow this currently)?

[dabrahams]

Hi @waydan, thanks for your interest!

the exception implementation relies on dynamic memory (causing non-deterministic execution time) and RTTI (bloating the image side). P0709 explains this is due to the way exceptions are specified in the language.

There's no need for dynamic memory allocation, and I don't think the paper says there is. Yes, some form of RTTI is needed, but as far as I can tell there's no reason its performance needs to be non-deterministic, especially if you only catch primitive types and final classes. I do see that the paper says “today’s dynamic exception types violate the zero- overhead principle, and do not have statically boundable space and time costs,” which is a statement more about the types that are typically thrown and caught than about the way the features are specified.

Will the Hylo specification make guarantees about how exceptions are raised such that dynamic memory is not required?

We intend that all the basic language features, including error handling, are available to applications built with only the Core library and no standard library, where the Core library is suitable for resource-constrained embedded environments without generalized dynamic allocation. This is a goal, for sure, but we're still a long way from working out the details of how to achieve it. The success of that effort will require input and attention from domain experts like you, so I hope you'll stay engaged.

It would be nice… if the offsets, ordering, and padding of structure data members could be explicitly specified in the source file.

I think that's probably achievable in effect using library features layered on top of our basic translation of tuple types into LLVM record layout; if I'm right I'd prefer to handle this relatively niche requirement that way, rather than accepting the added complexity that comes with specific language features to support it. But again, we'll need to keep open an ongoing discussion with domain experts to make sure the design works for these niches.

I wonder how memory-mapped registers could work in Hylo

I don't know much about them; I presume they are essentially global variables?

will I need unsafe statements?

1. If accessing such a register can cause undefined behavior (e.g. if there is a race condition), then yes, unsafe will appear somewhere. Otherwise, maybe not.
2. Need is a relative term. Anyone whose code review policy allows it can write a trivial wrapper for any unsafe construct and label the wrapper “safe” even if undefined behavior is possible. If you're really determined to lie to the system, and sacrifice static guarantees for simpler-looking code, you certainly can.

Will Hylo support volatile memory operations?

Depends what you mean by volatile. Do you mean the C++ meaning of the keyword (which IIRC has to do with signal handlers and is useful to almost nobody)?

Could I express an memory address at compile time in the source code?

It should be possible to create a pointer at compile time from the bit pattern of an integer constant, if that's what you mean.

[waydan]

We intend that all the basic language features, including error handling, are available to applications built with only the Core library and no standard library

Thank you for making this distinction. A common language core will, IMO, help adoption since many embedded system engineers mistakenly think memory will be dynamically allocated whenever a class is constructed and freed when destructed.

I don't know much about [memory-mapped registers]; I presume they are essentially global variables?

Spot on. Good architecture and hardware according layers can help localize modification to a thread. Some using Rust have tried modeling them as singletons and employed the borrow-checker to control access.

Depends what you mean by volatile. Do you mean the C++ meaning of the keyword (which IIRC has to do with signal handlers and is useful to almost nobody)?

I mean that reads and writes would not be eliminated by an optimizer. It's necessary because the programming model doesn't account for hardware modifying or being modified by a value in a memory location. Sometimes stronger sequential execution guarantees are required and atomics are applicable, but such a strong guarantee is not always necessary.

Thank you for all the feedback. I do hope I contribute to the language's development.