Re: HLL design

glen herrmannsfeldt <gah@ugcs.caltech.edu>
21 Oct 2006 13:54:50 -0400

          From comp.compilers

Related articles
HLL design free4trample@yahoo.com (fermineutron) (2006-10-21)
Re: HLL design gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-10-21)
Re: HLL design pjb@informatimago.com (Pascal Bourguignon) (2006-10-21)
Re: HLL design DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-10-21)
Re: HLL design mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-10-21)
Re: HLL design int2k@gmx.net (Wolfram Fenske) (2006-10-21)
Re: HLL design DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-10-21)
Re: HLL design free4trample@yahoo.com (fermineutron) (2006-10-21)
[6 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 21 Oct 2006 13:54:50 -0400
Organization: Compilers Central
References: 06-10-080
Keywords: design, performance
Posted-Date: 21 Oct 2006 13:54:50 EDT

fermineutron wrote:


> This is somewhat of a theoretical question for the experts here. Most
> of easy to use languages are too slow for any serious computing while
> the languages like C and assembly are somewhat of a pain to use. The
> key issues that i identyfy as pain include but not limited to,
> variable declaration array boundary checking, strict data types
> etc. Most can be solved by using extended variables that carry key
> information about the data in the variable within the variable, for
> example using the 1st byte to designate the data type of a variable,
> int, float double etc. using second byte to designate the number of
> dimensions in the variable lets say its N, then using N 4-byte
> integers to store dimension sizes, and this header is followed by the
> data itself.


This is pretty much the descriptor used by languages that pass arrays
by descriptor. PL/I, assumed shape arrays in Fortran, and probably
others. I don't know that they include the type, but the dimensions
and the address of the actual array.


> 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?


An array access takes one or two machine instructions per array
dimension on most machines. Add maybe four per dimension to do bounds
checking, so each takes three times longer.


Because of this, the VAX designers added a special instruction to do
array indexing with bounds checking. This instruction turned out to
be slower than doing it the usual way with separate instructions, and
so was rarely used.


Many compilers now have an option for bounds checking, and it is
a good idea to use it.


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


For an interpreted language like MatLab, Mathematica, R, etc., an
array access takes somewhat longer. The extra time to do bounds
checking, relative to the access itself, isn't so bad, and besides
people expect it.


> I am thinking about starting a project to write such a language, but
> before i imbark of such a great crusade i want to hear what people
> who are by far more experienced than me have to say about it?


Well, Java requires bounds checking, and with JIT on isn't so much
slower than compiled code. It is probably possible to make some
language design decisions that will make bounds checking easier.


If a compiler can determine at compile time that, for example, a loop
variable can't go outside the array, or can test the loop conditions
once instead of each time, it could be faster. I believe some
compilers do that, but I don't know that any language includes it in
the language definition.


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


Not really, but not doing the check is pretty much always faster
than doing it.


-- glen


Post a followup to this message

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