[COFF] Re: [TUHS] Re: crt0 -- what's in that name?

["G. Branden Robinson" <g.branden.robinson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5089 bytes --]

[Clem and TUHS dropped from CC]

Hi Paul,

At 2023-06-12T19:04:31-0400, Paul Winalski wrote:
> I don't think this remark was intended to denigrate Fortran in any
> way.  I took it as a wryly humorous way to make the observation that C
> and Fortran have different program startup semantics, and that there
> is other stuff that has to be done when firing up a program written
> wholly or partially in Fortran beyond what is needed to start up a C
> application.

It was really just a fart joke--you know, "breaking wind" and all that.
libcrt0.s -> libfrt0.s ...

But you're getting at an actual problem I had when trying to learn
linking and loading on Unix beyond the level of recipes keyed in by
rote.  (My upbringing was on systems with the most minimal conceivable
object file formats, and your runtime support was in either in ROM or
you provided it yourself.)  Being of a certain age, 'crt0' (a name
preserved by the GNU C compiler) looked to me for all the world like it
must have had to do with driving a CRT.  This made little sense to me,
especially when the darn thing got shoved into computation-only programs
that performed no I/O at all.  I could find no documentation, nor at
that time any local experts who could tell me what the heck "crt" was
_for_.  (The BSD advocates I knew back in the day suggested that this
was my fault for not locating and apprenticing myself to such a master;
the guild mentality was, and in some ways still is, powerful there.)

I am probably not the only person who was sent down an incorrect chain
of deductions by this "economical" naming convention; furthermore, one
employed for the sake of a file name that almost no one ever typed
anyway.

To bang an old drum of mine, while Unix culture pats itself on the back
for economizing keystrokes with an ad hoc compression scheme for every
name in sight, it too often overlooks what discarded in pursuit of this
form of minimality: clarity, lack of ambiguity, and ease of acquisition
by newcomers.

I get that Teletypes were hard to type on and baud rates were
punitively low.  But when Bell Labs got the Blit, the limitations that
motivated the original terseness were not only not discarded, but
retained and doubled down on.  "We're going multi-architecture for Plan
9, so let's allocate every machine architecture we'll ever be presented
with an identifier from a single-character alphanumeric namespace."

Madness.[1]

Decades after tcsh brought tab-completion to the shell-using masses, and
just as many decades after this feature was cloned by every Unix shell
that wasn't moribund, the defenders of keystroke minimality aren't
content to cultivate their own private name space of single-letter shell
functions, scripts, or aliases--instead they rebut the above by
complaining that GNU-style architecture triples are way too long.  Way
too long for what?  To type out in full?  Sure.  Too long to tell you
what ABI the objects produced are going to use?  No.

At least APL chose sigils that were tough to confuse with other things.

> Most operating system ABIs, Unix included, don't have a formalized
> mechanism for dealing with the differences between startup semantics
> of various programming languages.  They deal with the problem in an
> ad-hack fashion.  The one exception that I know of is VMS (now
> OpenVMS).  Tom Hastings was the architect who designed the original
> VAX/VMS ABI.  He was aware from the get-go that several programming
> languages had to be supported and he made sure that his design was
> general enough to allow programmers to write routines in the most
> suitable language for them, to mix and match modules written in
> different languages in the same program, and to easily make calls from
> one language to another.  It was a stroke of genius and I haven't seen
> its like in any other OS (several times I've wished it was there,
> though).

Thanks for mentioning this.  I think you had pointed this out some
months ago, but I had difficulty remembering the details of "who had
solved the ABI problem the right way a long time ago", but could not
remember enough of it to dredge it up even with repeated searches.

Unfortunately Google remains stymied even by the quite explicit terms

  "tom hastings" vax vms abi

...do you have a link to a white paper I could read?

I have an ecosystem in mind that might be receptive to the concept.

Regards,
Branden

[1]

  NAME
     0c, 1c, 2c, 5c, 6c, 7c, 8c, kc, qc, vc - C compilers
[...]
  DESCRIPTION

  These commands compile the named C files into object files for the
  corresponding architecture. If there are multiple C files, the
  compilers will attempt to keep $NPROC compilations running con
  currently.  Associated with each compiler is a string objtype, for
  example

  0c spim little-endian MIPS 3000 family
  1c 68000 Motorola MC68000
  2c 68020 Motorola MC68020
  5c arm little-endian ARM
  6c amd64 AMD64 and compatibles (e.g., Intel EM64T)
  7c alpha Digital Alpha APX
  8c 386 Intel i386, i486, Pentium, etc.
  kc sparc Sun SPARC
  qc power Power PC
  vc mips big-endian MIPS 3000 family

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]