Re: new IL: C (sort of...).



"Harold Aptroot" <harold.aptroot@xxxxxxxxx> wrote in message
news:2e7a3$4a314380$53558f0b$1854@xxxxxxxxxxxxxxxxxxxxxxxxxx
"Rod Pemberton" <do_not_have@xxxxxxxxxxxxx> wrote in message
news:h0pklu$k5i$1@xxxxxxxxxxx

bitfields? floats? unions? multiple integer and char types?
qualifiers?
volatile? const? void? void*?

I'd get rid of all those too... :-)
[...]
Rod Pemberton


Then how about graphics? (requires floats in many places)

So?

Is it important enough language feature to keep or implement in his IL? I'd
say "no." Floats/doubles are not a high use feature. He might keep because
they are needed to compile floating point.

E.g., by choosing all characters to be "unsigned char," he can eliminate
"signed char" from the IL. There will be a few situations where code
correction is needed to compensate for different range checks, but they can
be transformed.

Would you keep the double? It's even worse than a float..

No.

Interoperability with everything

I think that's part of the point. He can't get a 100% interoperability for
multiple languages with a generic IL. He'd need a highly specialized IL.
So, what does he need for a very _useful_ IL? He definately wants to keep
control-flow, procedures, integer arithmetic, characters, etc. If some of
the features he needs can be converted to simpler forms, then remove the
"compound" features...

No volatile? How about threading then?
No const? Doesn't matter for the code as much, but you'd put more load on
the optimizer..

C existed without these. These could be considered specialized
functionality - which, in my mind, justifies considering them for removal
from an IL. Does an IL based on C really need "const" once the
type-checking on the language has been done?

But throwing out bitfields and unions wouldn't hurt too much, you can
emulate both using other features..

Ditto for const, array declarations, void, void*, typedefs...

And void, well, just return zero I guess
Not too sure about the void pointer, I can't really think of a place where
it's absolutely required.

C existed without these too.


Rod Pemberton


.



Relevant Pages

  • Re: new IL: C (sort of...).
    ... multiple integer and char types? ... (requires floats in many places) ... Is it important enough language feature to keep or implement in his IL? ... the additional types offer a lot of value as well (smaller types for reduced storage and other uses, bigger types when one wants big values and is willing to pay the cost...). ...
    (comp.lang.misc)
  • Re: Illegal internal write?
    ... I think it is -- both in the feature itself, ... char*), would require the prototype. ... representation; in C89/90 this is nonnormatively 'intended' to allow ... OTOH, FILE in practice almost always is a struct, although not ...
    (comp.lang.fortran)
  • Re: new IL: C (sort of...).
    ... (requires floats in many places) ... I can then do most of the floating point via SSE (this is actually what I ... "signed char" from the IL. ... the register after noticing that float80 and float128, ...
    (comp.lang.misc)
  • Bit representation of a float
    ... curiosity. ... uses 8-bit bytes and 4-byte floats. ... int main{ ... pc = (char *)pf; ...
    (comp.lang.c)
  • Re: Fortran Features
    ... On the assumption that no feature should ... language and find it not nearly as useful as I expected. ... I don't find text labels all that useful where we already have them. ... You mean like overloading CHAR so that it takes ...
    (comp.lang.fortran)