public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Cut Hour <cuthour@gmail.com>
To: binutils@sourceware.org
Subject: Old story (30 years ago)
Date: Mon, 9 Jan 2023 19:21:25 +0900	[thread overview]
Message-ID: <c6d552eb-e572-c0dd-e4b0-c3f1bf93e74b@gmail.com> (raw)

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?


             reply	other threads:[~2023-01-09 10:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09 10:21 Cut Hour [this message]
2023-01-17 13:55 ` Nick Clifton
2023-01-17 15:28   ` Cut Hour
2023-01-24 13:27     ` Nick Clifton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6d552eb-e572-c0dd-e4b0-c3f1bf93e74b@gmail.com \
    --to=cuthour@gmail.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).