Re: HLL design

Hans-Peter Diettrich <>
21 Oct 2006 13:56:03 -0400

          From comp.compilers

Related articles
HLL design (fermineutron) (2006-10-21)
Re: HLL design (glen herrmannsfeldt) (2006-10-21)
Re: HLL design (Pascal Bourguignon) (2006-10-21)
Re: HLL design (Hans-Peter Diettrich) (2006-10-21)
Re: HLL design (Dmitry A. Kazakov) (2006-10-21)
Re: HLL design (Wolfram Fenske) (2006-10-21)
Re: HLL design (Hans-Peter Diettrich) (2006-10-21)
Re: HLL design (fermineutron) (2006-10-21)
Re: HLL design (Daniel C. Wang) (2006-10-24)
Re: HLL design ( (2006-10-24)
[4 later articles]
| List of all articles for this month |

From: Hans-Peter Diettrich <>
Newsgroups: comp.compilers
Date: 21 Oct 2006 13:56:03 -0400
Organization: Compilers Central
References: 06-10-080
Keywords: performance, design
Posted-Date: 21 Oct 2006 13:56:03 EDT

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

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 ;-)


Post a followup to this message

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