Hi,
while undoubtedly interesting, I'm less enthusiastic than both Martins.
I don't think there's a need for all encompassing programming language
aimed at system programming.
I'd rather argue that each functional domain of an OS is distinct
enough to warrant separate approach.
Let me explain. I see an OS as a collection of separate domains, for example:
* architecture support domain
- I don't think we can do much better than c/assembler here,
although generating the code from higher level machine description
would be nice
* scheduler, and memory management*
- no reason to use C here, I think your proposal can be a good fit,
needs to call ^^ for things like context switches, timer, and
pagetable/TLB manipulation
* higher level services (tops of stacks)*
- also might be a fit
* device drivers
- there is a nice paper called "P: Asynchronous Even-Driven
Programming" out of ms research, where they propose new language for
writing device drivers (and reactive systems in general) and
demonstrate it on win8 usb hub driver (150 lines of P code for driver
logic, our hub driver is 1500, and I'm pretty sure our driver handles
much less).
* I never cared much about these, so others probably know better about
the domain requirements. I split scheduler/MM from stacks, mostly
because of their location in HelenOS (kernel vs. uspace).
by delegating functionality to these domains with link-time
interoperability. The language can get rid of stuff like (I know these
are Martin's ideas) specific data sizes/alignemnt/endian, blob
inclusion, packing, and other low level things.
TLDR:
I think a C replacement should be more than one language trying to be
perfect and do everything, but rather a collection of languages, one
for each domain.
Jan
On Mon, Feb 17, 2014 at 5:30 PM, Jiří Zárevúcky
<[email protected]> wrote:
> On 17 February 2014 21:03, Martin Sucha <[email protected]> wrote:
>>
>> I would add some compiler features:
>> - ability to tell the compiler to generate several compiled versions of
>> the same code with different compiler hints and switch between them at
>> runtime (using arbitrary expression to decide which variant to use),
>> i.e. speed vs. power-saving optimized code [inspired by one of the
>> LLVM talks @ FOSDEM]
>>
>
> That is an interesting possibility. Using the same package with different
> compiled-in "hints"/"traits"/"flags" would allow for all kinds of neat
> stuff.
>
>>
>> I guess it could something like:
>> switch_hints {
>> if (is_powersave_on()) powersave
>> else default
>> }
>> {
>> // some code
>> }
>>
>> It could be defined such that a compiler that totally ignores the
>> hints, generates a single variant and just executes the expression(s)
>> is conformant
>
>
> For that definition to work sanely, you would have to ensure that the
> alternatives are functionally equivalent. In contrast to C, I don't want to
> put any expectations into the semantics that depend solely on the
> programmers attention to nasty details and corner cases. And requiring
> compiler to check the equivalence would cripple the expressiveness of the
> hinted code possibly much more than boolean expression contracts do for all
> the other code.
>
> However, I can see this mechanism used to swap non-equivalent
> implementations. Not with such a switch though. That would be kind of ugly.
> The Go solution is to tag entire files, and only include in a build the
> files that match the build tags. A similar solution could be devised on a
> more fine-grain scale (the tags would be defined as part of import instead
> of just once during the build).
>
>
> -- Jirka Z.
>
> _______________________________________________
> HelenOS-devel mailing list
> [email protected]
> http://lists.modry.cz/listinfo/helenos-devel
>
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
