Re: HLL design

fermineutron wrote:


> Assuming that the system that is to work with such variables is
> inteligently designed, do you think it will be significantly slower
> than C? Is there a good reason why there is no "efficient" programming
> language which uses such or simmilar system to store variables?


The amount of extra data doesn't count at runtime, it's the *usage* of
such information. In C++ you can use classes and templates, to make
the objects behave as expected. With debug and retail modes, if you
like...


Sometimes more data can result in faster code, e.g. when the length of
a string is stored explicitly, and must not be determined by searching
for an '\0' string terminator.




> Basically i want a programming language which has the speed and
> flexibility of C, while user friendlenness of MatLab.


It's a matter of compiletime/runtime checks. When a language does not
allow for compiletime checks (of pointer usage...), everything must be
done at runtime. So it's a matter of the design of the objects, which
shall replace the known unsafe data types, and how far the users of
your system (language or class library) accept the resulting
restrictions, overhead in thinking and typing etc.




> Is it really impossible to design a compiler which translates higher
> level code than C into efficient assembly?


The efficiency should not be measured in an atomic view. Global
optimization can be improved by an appropriate formalism in a HLL
(high level language), but hardly in a LLL (low level, assembly,
C...). If you want type safety, bounds checking etc., the according
instructions will bloat assembly code as well. But only HLL code, with
appropriate additional information about data types, subroutine
arguments etc., will allow to determine, where the checks can be
safely *omitted* at runtime.


IMO ;-)


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.