Old story (30 years ago)

Old story (30 years ago)

[Cut Hour]

Hello.

As an extension to ELF format that does not lose generality, it is
conceivable that symbols can perform four arithmetic operations with
other symbols and constants during resolution.  Symbol resolution
information may be stored in Reverse Polish.  How much does this
reduce recompilation of source files?

The original motivation was the problem of recompilation caused by
the advent of C++.  What's new in OOP?  It's inheritance.
Encapsulation without inheritance can be done in plain C without
recompilation problems.  So what is inheritance?  It's the offset of
member variables and member functions. It is not good to hard-code
this at compile time.  Should be deferred until link time.

A long time ago, I tried to create a language in which every class
had a uniform method table and all methods were called via a single
pointer, and to see how practical it would be.  I thought that it
would be possible to create a suitable translator to C, but I was
frustrated because of such a problem.  The conclusion is that "the
current compiler infrastructure (such as binutils) assumes ONLY
STRUCTURED PROGRAMMING".

I don't know very well about Clang or LLVM.  So this might be
already out of date.  Any need for this extended ELF do you think?

Re: Old story (30 years ago)

[Nick Clifton]

Hi Cut,

> As an extension to ELF format that does not lose generality, it is
> conceivable that symbols can perform four arithmetic operations with
> other symbols and constants during resolution.

This sounds very much like the "complex relocations" feature supported
by some architectures (eg MEP, RL78).

> I don't know very well about Clang or LLVM.  So this might be
> already out of date.  Any need for this extended ELF do you think?

I would say probably not.  Obviously support for high level languages
is already working with ELF as it is.  So if it isn't broken - don't
fix it.

This is not to say that exploring the idea is not worthwhile.  It
might produce some interesting results.  But I would be hesitant about
applying it to a generic tool like the linker without a real need.

Cheers
   Nick

Re: Old story (30 years ago)

[Cut Hour]

Hi, Nick,
>> I don't know very well about Clang or LLVM.  So this might be
>> already out of date.  Any need for this extended ELF do you think?
>
> I would say probably not.  Obviously support for high level languages
> is already working with ELF as it is.  So if it isn't broken - don't
> fix it.

It might be broken if we want to only recompile basically touched source
files like the programming in C.  Or is this cleared in LLVM?

> This is not to say that exploring the idea is not worthwhile.  It
> might produce some interesting results.  But I would be hesitant about
> applying it to a generic tool like the linker without a real need.

I myself had needed it.  My plan was like this.  Every instance has a
ptr to its class.  Every class has a method table (array of ptr to
function).  All methods are called via a ptr in the method table.
The syntax is almost the same as ObjC.  Binutils (for the structured
programming) is what makes this simplest OO language so hard to come
by.  Neither C++ nor ObjC nor Java pointed that out.  Again, is this
cleared in LLVM?

Re: Old story (30 years ago)

[Nick Clifton]

Hi Cut Hour,

>> This is not to say that exploring the idea is not worthwhile.  It
>> might produce some interesting results.  But I would be hesitant about
>> applying it to a generic tool like the linker without a real need.
> 
> I myself had needed it.  My plan was like this.  Every instance has a
> ptr to its class.  Every class has a method table (array of ptr to
> function).  All methods are called via a ptr in the method table.
> The syntax is almost the same as ObjC.  Binutils (for the structured
> programming) is what makes this simplest OO language so hard to come
> by.  Neither C++ nor ObjC nor Java pointed that out.  Again, is this
> cleared in LLVM?

I do not think so.  I cannot say for sure, but linking with LLVM (and
its linker LLD) is basically the same process as used by the binutils
linker.  The implementations differ, but what they do is basically the
same.

Cheers
   Nick