> From: richardm@cogs.sussex.ac.uk
>
> Don't you just love the Usenet? I feared there wasn't a simple answer to my
> question. Now I get to have a public argument with members of the faculty!
Wasn't meant as an argument, honest :-) I was just attempting to point
out that their are no "hard lines" which separate "systems" languages
from other HLLs. Especially with the rather dodgy concept of a "runtime
environment".
> Adrian Howard (adrianh@cogs.susx.ac.uk) wrote:
> : Both Poplog Pop-11 (and most MLs that I am aware of) compile to native machi
> : code --- they are *not* interpreted. This seems to be a common misconception.
> : There are also versions of C and Pascal that are interpreted! Unix shell
> : scripts and Perl (usually used for "systems" programming) are interpreted.
>
> Yes, I am aware of the difference between interpreted and compiled languages.
> I am aware that Poplog pop11 is compiled, but how much code does the compiler
> generate for say an = operator? Does it insert all the code do the key
> checking of the operands to make sure they are numeric, do the necessary type
> conversions etc. or does it just call a common library for these functions?
Well, this is rather an unfair comparison since we should be talking
about the == operator if we're going to compare Pop-11 and C. In C you
would have to write custom code for most of the operations performed by
the Pop-11 = operator.
If my recent poring over assembler was correct, == compiles to a compare
and a couple of branches which stack true/false. No calls to strange
demonic libraries necessary :-)
In general the decision on whether to inline code or not is a compiler
implementation decision. You can change your mind without altering the
semantics of the language.
In part, you are correct in saying that Pop-11 does a lot of runtime type
checking which does slow it down compared to languages like C/Pascal. However,
languages like Common LISP and SML do not suffer these problems. The Standard
New Jersey ML compiler produces darn spiffy code. Also, extensions like
ObjectClass and the stack-parsing work by Robin Popplestone can, in theory,
give a Pop-11 compiler enough information to plant much more efficient code.
> I
> fear it does the latter. If the compiler just generates multiple calls to a
> massive library of code that must be present to run the program, then it might
> as well be interpreted! Or you might as well interpret the syspop. Well, maybe
> thats a bit harsh, but you get the idea.
No more harsh that I can be with C. Go look at the size of /lib. If you
investigate where a great deal of C programs spend the majority of their
time you may well be surprised.
All languages use libraries of common code. The cost of a jump and
return is very small. It can also produce more efficient code that
inlining since it can reduce page faults
> : Runtime environments? Unfortunately these are also rather difficult to define.
> : Let's just look at the issue you raised --- heap management. What is the
> : difference between Pop-11 using a garbage collector and C using malloc et al?
> : Not a lot really [1]. Both are necessary for any useful program in either
> : language. Both are used at runtime.
>
> Malloc doesn't manage the heap though. All it does is allocate memory. It
> can't grabage collect because it doesn't know who holds pointers to the
> pieces of memory it would have to move. Poplog on the other have can garbage
> collect because the run-time environment keeps track of all the identifiers
> and their associated values/pointers. This is what I mean by run-time
> environment.
I beg to differ :-). First off, most people would class malloc/free as a
form of heap management (along with reference counting, GC, or
whatever). Malloc does not just "allocate memory". It also keeps track
of the memory it allocates so it can free it, merge contiguous free
blocks, realloc it, etc. A complete malloc/free library is a non-trivial
piece of code.... of a similar level of complexity to a simple garbage
collector. Why doesn't all this data which is maintained at program
execution time count as a "runtime environment"?
Malloc/free is just a form of heap management which leaves more freedom
for the programmer (for either efficiency gains, or mistakes --- mainly
the latter in my experience).
The speed advantage of malloc/free over GC is usually over estimated.
The decrease in development time and increase in code modularity also
tends to be overlooked.
GC systems *are* used in the real world (for example, the work by
Wilson/Hennessey on real-time GC --- OOPSLA 93 I think). In many real
world applications some form of GC is necessary to prevent heap
fragmentation in all scenarios --- far too many C programs just cross
their fingers and hope for the best.
Anyway... this is all getting a bit off topic :-)
> You can get heap management facilities in C++ by using a complex set of
> storage objects. Borland supplies such an "ObjectClass" library with its
> compilers and it works quite well. The only problem is, that if you are lazy
> and use it instead of taking the time to make you code allocate/deallocate
> memory in the right order so it doesn't leave holes in the core, then your
> program will run as fast as the pop system does on tsunb[1].
This is almost certainly due to a bad C++ implementation (language or
library).
If used properly C++ will produce code of the same order of magnitude
efficiency as C --- and be a damn sight more readable and modular.
Unfortunately, in my experience, many C++ programmers tend to produce a
mish-mash of C and C++ style code which is one of the reasons I dislike
the language (despite it having several nice features).
> The only reason I referred to C as a systems language was that the course on
> which it is taught is called "systems programing". Interpreted languages like
> perl may be used for maintaining the system, but the other meaning of systems
> language is one used to write the operating system.
True, but as I mentioned in my last missive Pop has been used to write
an multi-user OS. There have also been LISP based operating systems.
There are many valid reasons for teaching C, including things like:
o The RealWorld(tm) is rather attached to it, so C programming is a
useful (indeed, probably necessary) skill for students to possess.
o For most of its life Unix has been implemented mainly in C, so
Unix systems programming is very C oriented.
o It may be pedagogically useful to teach how to develop high-level
features in a language lacking those features.
There are also less valid reasons, such as tradition. However, IMHO, C
does not define what a systems programming language is, or should be.
In fact, in these days when we have to try and prove the correctness of
operating systems and code, C is one of the last languages I would
choose (Pop wouldn't be much good in its current state either :-)
I can't resist adding the usual quote that C is
"a language that combines all the elegance and power of assembly
language with all the readability and maintainability of assembly
language".
> If you take the example
> from the paragraph above, C++ does resolve into machine language more cleanly
> than pop11, but you still wouldn't write an operating system with it, well not
> the kernel anyway.
I don't see why not. With the exception of the bits of the kernel which
would have to be created in machine dependent code in any language, C++
should be not be significantly worse speed-wise than using C. IMHO if it
was being used by a decent programmer it would also cut development time
and produce more maintainable code.
Adrian
aids (adrianh@cogs.susx.ac.uk) ObDisclamer: Poplog used to pay my wages
Phone: +44 (0)1273 678367 URL: http://www.cogs.susx.ac.uk/users/adrianh/
|