Den 2022-03-22 kl. 20:30, skrev Bill Gunshannon:
> On 3/22/22 14:42, Simon Clubley wrote:
>> On 2022-03-22, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>>
>>> When talkning about these kind of systems, you need to
>>> qualify "support". It is not that you are able to run
>>> a C-compiler on any of those "platforms". But there are
>>> dev tools available for Windows/Linux or such, that does
>>> have a C-compiler included for these platforms.
>>>
>>> It is more correct to talk about C-compilers that support
>>> these platforms, not the other way around.
>>>
>>
>> That's a fair point Jan-Erik. When talking about embedded environments,
>> we really are indeed talking about C compilers that support the embedded
>> environment as a target environment, not a host environment.
>>
>
> In the two examples I gave, Z80 and 6809 the C-compilers do support
> the environment they run in.  And do it natively.
>
> bill
>

Compilers running on Z80 and/or 6809 plattforms natively?
Maybe it is tecnicaly possible but I do not see the point.

On 3/23/22 03:36, Jan-Erik Söderholm wrote:
> Den 2022-03-22 kl. 20:30, skrev Bill Gunshannon:
>> On 3/22/22 14:42, Simon Clubley wrote:
>>> On 2022-03-22, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>>>
>>>> When talkning about these kind of systems, you need to
>>>> qualify "support". It is not that you are able to run
>>>> a C-compiler on any of those "platforms". But there are
>>>> dev tools available for Windows/Linux or such, that does
>>>> have a C-compiler included for these platforms.
>>>>
>>>> It is more correct to talk about C-compilers that support
>>>> these platforms, not the other way around.
>>>>
>>>
>>> That's a fair point Jan-Erik. When talking about embedded environments,
>>> we really are indeed talking about C compilers that support the embedded
>>> environment as a target environment, not a host environment.
>>>
>>
>> In the two examples I gave, Z80 and 6809 the C-compilers do support
>> the environment they run in.  And do it natively.
>>
>> bill
>>
>
> Compilers running on Z80 and/or 6809 plattforms natively?
> Maybe it is tecnicaly possible but I do not see the point.

Why would you think it was not technically possible? Systems
like the Z80 and 6809 are complete computers and support lots
of languages just like other systems. On my still running Z80's
I have not only C but BASIC, Pascal, COBOL, Fortran, APL. It
even has limited TCP/IP abilities thru an add-on board that
also provides emulated hard disks on CF cards.

On the 6809, which by the way is running multi-user/multi-
tasking, I have C, Pascal, Logo and BASIC. COBOL was
available, but I never had it. It also supports TCP/IP
and emulated hard disks over a very fast serial connection.

And if I told you what these machines actually are you would
probably be rolling on the floor laughing.

People today are spoiled. They don't remember when we used to
run the world on these much smaller systems.

bill

Den 2022-03-23 kl. 12:29, skrev Bill Gunshannon:
> On 3/23/22 03:36, Jan-Erik Söderholm wrote:
>> Den 2022-03-22 kl. 20:30, skrev Bill Gunshannon:
>>> On 3/22/22 14:42, Simon Clubley wrote:
>>>> On 2022-03-22, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>>>>
>>>>> When talkning about these kind of systems, you need to
>>>>> qualify "support". It is not that you are able to run
>>>>> a C-compiler on any of those "platforms". But there are
>>>>> dev tools available for Windows/Linux or such, that does
>>>>> have a C-compiler included for these platforms.
>>>>>
>>>>> It is more correct to talk about C-compilers that support
>>>>> these platforms, not the other way around.
>>>>>
>>>>
>>>> That's a fair point Jan-Erik. When talking about embedded environments,
>>>> we really are indeed talking about C compilers that support the embedded
>>>> environment as a target environment, not a host environment.
>>>>
>>>
>>> In the two examples I gave, Z80 and 6809 the C-compilers do support
>>> the environment they run in.  And do it natively.
>>>
>>> bill
>>>
>>
>> Compilers running on Z80 and/or 6809 plattforms natively?
>> Maybe it is tecnicaly possible but I do not see the point.
>
> Why would you think it was not technically possible? Systems
> like the Z80 and 6809 are complete computers and support lots
> of languages just like other systems.  On my still running Z80's
> I have not only C but BASIC, Pascal, COBOL, Fortran, APL.  It
> even has limited TCP/IP abilities thru an add-on board that
> also provides emulated hard disks on CF cards.
>
> On the 6809, which by the way is running multi-user/multi-
> tasking, I have C, Pascal, Logo and BASIC.  COBOL was
> available, but I never had it.  It also supports TCP/IP
> and emulated hard disks over a very fast serial connection.
>
> And if I told you what these machines actually are you would
> probably be rolling on the floor laughing.
>
> People today are spoiled.  They don't remember when we used to
> run the world on these much smaller systems.
>
> bill
>

Well, I grew up with the IMSAI and such system. Z80, 6800,
6809, SC/MP and so on up to todays PIC16/PIC18 are well known
to me. But OK. You could back in time write a small compiler
to run on these, but it would not be up do todays standards.

On 3/23/22 12:27, Jan-Erik Söderholm wrote:
> Den 2022-03-23 kl. 12:29, skrev Bill Gunshannon:
>> On 3/23/22 03:36, Jan-Erik Söderholm wrote:
>>> Den 2022-03-22 kl. 20:30, skrev Bill Gunshannon:
>>>> On 3/22/22 14:42, Simon Clubley wrote:
>>>>> On 2022-03-22, Jan-Erik Söderholm <jan-erik.soderholm@telia.com>
>>>>> wrote:
>>>>>>
>>>>>> When talkning about these kind of systems, you need to
>>>>>> qualify "support". It is not that you are able to run
>>>>>> a C-compiler on any of those "platforms". But there are
>>>>>> dev tools available for Windows/Linux or such, that does
>>>>>> have a C-compiler included for these platforms.
>>>>>>
>>>>>> It is more correct to talk about C-compilers that support
>>>>>> these platforms, not the other way around.
>>>>>>
>>>>>
>>>>> That's a fair point Jan-Erik. When talking about embedded
>>>>> environments,
>>>>> we really are indeed talking about C compilers that support the
>>>>> embedded
>>>>> environment as a target environment, not a host environment.
>>>>>
>>>>
>>>> In the two examples I gave, Z80 and 6809 the C-compilers do support
>>>> the environment they run in.  And do it natively.
>>>>
>>>> bill
>>>>
>>>
>>> Compilers running on Z80 and/or 6809 plattforms natively?
>>> Maybe it is tecnicaly possible but I do not see the point.
>>
>> Why would you think it was not technically possible? Systems
>> like the Z80 and 6809 are complete computers and support lots
>> of languages just like other systems.  On my still running Z80's
>> I have not only C but BASIC, Pascal, COBOL, Fortran, APL.  It
>> even has limited TCP/IP abilities thru an add-on board that
>> also provides emulated hard disks on CF cards.
>>
>> On the 6809, which by the way is running multi-user/multi-
>> tasking, I have C, Pascal, Logo and BASIC.  COBOL was
>> available, but I never had it.  It also supports TCP/IP
>> and emulated hard disks over a very fast serial connection.
>>
>> And if I told you what these machines actually are you would
>> probably be rolling on the floor laughing.
>>
>> People today are spoiled.  They don't remember when we used to
>> run the world on these much smaller systems.
>>
>> bill
>>
>
> Well, I grew up with the IMSAI and such system. Z80, 6800,
> 6809, SC/MP and so on up to todays PIC16/PIC18 are well known
> to me. But OK. You could back in time write a small compiler
> to run on these, but it would not be up do todays standards.
>

Define today's standards. :-)

Certainly not ANSI but some of us don't really care. K&R was
good enough to develop one of the most prevalent OSes in use
today. What more is needed?

As for the other languages. I run the same Fortran that was in
use on everything from minis to mainframes. Full Pascal on both
the Z80 and 6809. Same COBOL that ran on Primes, Univac 1100, RSX,
RSTS, and even VMS. And a version of BASIC on the 6809 that is
far beyond the BASIC that came out on the PC years later. And APL
by its very nature is a perfect fit for these systems. There were
a number of other languages, PILOT, Smalltalk, Lisp etc. but they
weren't really any more successful on bigger machines.

I wonder how much of this notion that small systems aren't useful
for anything but playing games contributed to companies like DEC
missing the boat when the micro world came along.

bill

On 2022-03-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <t1d53c$ges$1@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>>BTW #2, you can only easily call C++ code from a non-C++ program by
>>providing a C interface in the C++ library so you are back to using
>>C as an interface language even with C++...
>
> That's not precisely true; you're using an ABI that the C
> compiler targets, but that's qualitatively different than using
> the C language. For example, in Rust, I can define structures
> that use the layout of the system's native ABI, or functions
> that use the ABI's calling convention, etc. In my work, that
> usually implies calling between Rust and primitives written in
> assembly, but not C. In some sense, the connection with C is
> incidental, though admittedly many such ABIs were designed as a
> target for C primarily.
>

Does Rust have a C++ type name mangling problem when trying to call
a Rust library function from C ?

It seems that everyone falls back to C interface mode when trying
to export functions for use by another language. A quick look around
seems to show that Rust does the same.

It would be nice to have a richer interface standard that handles calling
between both OO and procedural languages natively but we are back once
again to C being viable if not ideal.

(And before anyone mentions the VMS common language environment, it
doesn't have support for OO languages.)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-03-22, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 3/22/22 14:38, Simon Clubley wrote:
>>
>> BTW #2, you can only easily call C++ code from a non-C++ program by
>> providing a C interface in the C++ library so you are back to using
>> C as an interface language even with C++...
>
> Once again, languages don't define calling sequences, compilers do.
>

Even ignoring the other issues, the nature of C++ means that name
mangling is a real problem if you try to directly call C++ code from
a non-C++ language.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-03-23, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> Certainly not ANSI but some of us don't really care. K&R was
> good enough to develop one of the most prevalent OSes in use
> today. What more is needed?
>

K&R was dumped with great gusto once ANSI C became available
(and rightly so). :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/23/2022 12:44 PM, Bill Gunshannon wrote:

>
> I wonder how much of this notion that small systems aren't useful
> for anything but playing games contributed to companies like DEC
> missing the boat when the micro world came along.

At a guess, I'd say that gamers feel they need the most powerful systems. They
would be wrong. What they actually want is really good and fast graphics.

If DEC had taken games seriously, they might have prospered. Come up with
rather inexpensive systems affordable to individuals, and sold a lot of them.
DEC never had the concept of "cheap".

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <ja113lFj1nhU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>Define today's standards. :-)

Language standards published any time this century. :-)

>Certainly not ANSI but some of us don't really care. K&R was
>good enough to develop one of the most prevalent OSes in use
>today. What more is needed?

Unix systems of today don't use K&R C, and with good reason. I
did a port of 7th Edition to the 68010 with a 68451 MMU a few
years ago, and updated the code to ISO C11. Just adding
prototypes found bugs.

>As for the other languages. I run the same Fortran that was in
>use on everything from minis to mainframes. Full Pascal on both
>the Z80 and 6809. Same COBOL that ran on Primes, Univac 1100, RSX,
>RSTS, and even VMS. And a version of BASIC on the 6809 that is
>far beyond the BASIC that came out on the PC years later. And APL
>by its very nature is a perfect fit for these systems. There were
>a number of other languages, PILOT, Smalltalk, Lisp etc. but they
>weren't really any more successful on bigger machines.
>
>I wonder how much of this notion that small systems aren't useful
>for anything but playing games contributed to companies like DEC
>missing the boat when the micro world came along.

You can certainly do all kinds of useful stuff on small systems,
but in this day and age it begs the question: why? Aside from
an interesting academic exercise, I don't much see the point
of a hosted environment on a z80 or 6809, particularly when a
Raspberry Pi Zero costs $5 or something and gives you so much
more. Use those devices as a _target_ platform for something?
Sure. But a host? Why bother?

- Dan C.

In article <t1fpab$v69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-03-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t1d53c$ges$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>>BTW #2, you can only easily call C++ code from a non-C++ program by
>>>providing a C interface in the C++ library so you are back to using
>>>C as an interface language even with C++...
>>
>> That's not precisely true; you're using an ABI that the C
>> compiler targets, but that's qualitatively different than using
>> the C language. For example, in Rust, I can define structures
>> that use the layout of the system's native ABI, or functions
>> that use the ABI's calling convention, etc. In my work, that
>> usually implies calling between Rust and primitives written in
>> assembly, but not C. In some sense, the connection with C is
>> incidental, though admittedly many such ABIs were designed as a
>> target for C primarily.
>>
>
>Does Rust have a C++ type name mangling problem when trying to call
>a Rust library function from C ?

No. You can export unmangled names trivially.

>It seems that everyone falls back to C interface mode when trying
>to export functions for use by another language. A quick look around
>seems to show that Rust does the same.

I suppose that if one's definition of a well-defined ABI is what
you are calling a "C interface mode" that's true, but most ABIs
are language-independent.

>It would be nice to have a richer interface standard that handles calling
>between both OO and procedural languages natively but we are back once
>again to C being viable if not ideal.

It's curious to me how VMS had this from very early on (e.g.,
https://vmssoftware.com/docs/VSI_CALLING_STD.pdf) and it was
rightfully lauded as a boon for cross-language interoperability,
but when people point to ABIs on other systems it's assumed to
be a C thing.

>(And before anyone mentions the VMS common language environment, it
>doesn't have support for OO languages.)

Perhaps you mean that it doesn't have baked-in support for
method dispatch via vtables and the like. But then, the System
V ABI for modern architectures does (or rather, it defers to the
Itanium ABI). Indeed, the latest VSI caling standard document
refers to the SysV C++ ABI, which refers to the Itanium ABI,
which specifies object layout and method invocation in detail:

https://itanium-cxx-abi.github.io/cxx-abi/abi.html

So in some sense, a lot of things _are_ specified, by the VMS
standard, at least for one "OO" language.

- Dan C.

In article <t1fq1e$e3e$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 3/23/2022 12:44 PM, Bill Gunshannon wrote:
>
>>
>> I wonder how much of this notion that small systems aren't useful
>> for anything but playing games contributed to companies like DEC
>> missing the boat when the micro world came along.
>
>At a guess, I'd say that gamers feel they need the most powerful systems. They
>would be wrong. What they actually want is really good and fast graphics.
>
>If DEC had taken games seriously, they might have prospered. Come up with
>rather inexpensive systems affordable to individuals, and sold a lot of them.
>DEC never had the concept of "cheap".

I saw a presentation by Olson once that I found prescient.

In a lot of ways, DEC had a vision that I actually find very
compelling. It seemed to be a mixture of different systems of
varying power, all networked together, with support for multiple
user interfaces: some folks would be sitting in front of
powerful workstations, others in front of cheap serial
terminals; both would draw from services and resources provided
by more powerful server machines of different kinds. It wasn't
cheap, but it was good.

DEC certainly seems to have missed the PC boat (or, rather, it
entered the race after it was already too late to win), much to
its detriment. But one wonders whether, in the end, they were
"right", but just too far forward thinking for the time.

- Dan C.

On 3/23/22 15:24, Dan Cross wrote:
> In article <ja113lFj1nhU1@mid.individual.net>,
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> Define today's standards. :-)
>
> Language standards published any time this century. :-)

Language standards with what purpose? :-)

>
>> Certainly not ANSI but some of us don't really care. K&R was
>> good enough to develop one of the most prevalent OSes in use
>> today. What more is needed?
>
> Unix systems of today don't use K&R C, and with good reason. I
> did a port of 7th Edition to the 68010 with a 68451 MMU a few
> years ago, and updated the code to ISO C11. Just adding
> prototypes found bugs.

Probably would have been found with lint if someone had bothered
to try. But, take any of the packages available today (start
with GNU stuff) turn on all the warnings and stand back and watch
just how is ignored on their production versions. Programmers
seem to have this feeling that warnings (and even errors if you
can convince the compiler to ignore them) are OK if you don't
see them and the easiest way to do that is don't look.

>
>> As for the other languages. I run the same Fortran that was in
>> use on everything from minis to mainframes. Full Pascal on both
>> the Z80 and 6809. Same COBOL that ran on Primes, Univac 1100, RSX,
>> RSTS, and even VMS. And a version of BASIC on the 6809 that is
>> far beyond the BASIC that came out on the PC years later. And APL
>> by its very nature is a perfect fit for these systems. There were
>> a number of other languages, PILOT, Smalltalk, Lisp etc. but they
>> weren't really any more successful on bigger machines.
>>
>> I wonder how much of this notion that small systems aren't useful
>> for anything but playing games contributed to companies like DEC
>> missing the boat when the micro world came along.
>
> You can certainly do all kinds of useful stuff on small systems,
> but in this day and age it begs the question: why? Aside from
> an interesting academic exercise, I don't much see the point
> of a hosted environment on a z80 or 6809, particularly when a
> Raspberry Pi Zero costs $5 or something and gives you so much
> more. Use those devices as a _target_ platform for something?
> Sure. But a host? Why bother?

Because I already have them. Because I like nostalgia. Other
reasons I'm sure. Oh, and I use the Pi and Arduinos as well.
But they just aren't as much fun. Lately I have been thinking
about tasking another look at Amoeba. Imagine what could be
done with an Amoeba cluster of Pi's. :-)

bill

On 3/23/2022 2:35 PM, Simon Clubley wrote:
> It seems that everyone falls back to C interface mode when trying
> to export functions for use by another language.

Not really.

Almost all languages has a way to specify:
- do not mangle/decorate the function name
- use platform specific calling convention

And some like to call that C interface.

But it really isn't.

Not mangling/decorating is a common concept.

Platform specific calling conventions are
not C specific.

VMS calling convention is not. The stdcall is
not. The cdecl comes from the C world
as the name indicates, but are not
tied to C.

The only interfaces that are really C interfaces
are when the declaration does something under the
hood to actually match C expectations like
passing a string as a zero terminated byte array
even though the language use a different convention
for strings.

Arne

On 3/23/2022 4:58 PM, Arne Vajhøj wrote:
> On 3/23/2022 2:35 PM, Simon Clubley wrote:
>> It seems that everyone falls back to C interface mode when trying
>> to export functions for use by another language.
>
> Not really.
>
> Almost all languages has a way to specify:
> - do not mangle/decorate the function name
> - use platform specific calling convention
>
> And some like to call that C interface.

Because C (or C++) are very frequently the
calling language.

> But it really isn't.
>
> Not mangling/decorating is a common concept.
>
> Platform specific calling conventions are
> not C specific.

Arne

On 3/23/22 16:58, Arne Vajhøj wrote:
>
> The only interfaces that are really C interfaces
> are when the declaration does something under the
> hood to actually match C expectations like
> passing a string as a zero terminated byte array
> even though the language use a different convention
> for strings.

I've even done that from COBOL. As long as you know
what the called routine wants you can call any language
from any other language.

bill

In article <ja1e8sFlhdrU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 3/23/22 15:24, Dan Cross wrote:
>> In article <ja113lFj1nhU1@mid.individual.net>,
>> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> Define today's standards. :-)
>>
>> Language standards published any time this century. :-)
>
>Language standards with what purpose? :-)

Well, taking advantage of new hardware capabilities, better
understanding of the use and semantics of a language, really any
number of things.

For example, recent C and C++ standards define standard memory
models for the abstract virtual machine they describe, and
define standard interfaces for atomic operations, so that one
can write portable parallel code.

In some cases, old interfaces that are dangerous or ill
conceived are deprecated, c.f. `gets`.

COBOL people like to point out that the quip about a "65 year
old language" is inaccurate since more recent revisions of the
language have changed it to add useful modern functionality.
However, that's not useful if one can't get a toolchain that
supports those more recent standards.

>>> Certainly not ANSI but some of us don't really care. K&R was
>>> good enough to develop one of the most prevalent OSes in use
>>> today. What more is needed?
>>
>> Unix systems of today don't use K&R C, and with good reason. I
>> did a port of 7th Edition to the 68010 with a 68451 MMU a few
>> years ago, and updated the code to ISO C11. Just adding
>> prototypes found bugs.
>
>Probably would have been found with lint if someone had bothered
>to try.

What makes you think they didn't? The same group that liberated
`lint` from Johnson's compiler wrote 7th Edition, after all.
Lint doesn't catch all of these problems.

But moreover, why go to an extra step of running a separate tool
if the compiler will do it for you? Prototypes and well-typed
formals in function definitions were a boon to both correctness
and readability, as it turns out. I'd rather have compilation
fail due to an incompatible type mismatch than rely on everyone
changing code to run some external tool.

>But, take any of the packages available today (start
>with GNU stuff) turn on all the warnings and stand back and watch
>just how is ignored on their production versions. Programmers
>seem to have this feeling that warnings (and even errors if you
>can convince the compiler to ignore them) are OK if you don't
>see them and the easiest way to do that is don't look.

Three points here.

First of all, what does that have to do with anything? Poor
hygiene around warnings is orthogonal to the desire to run code
written to a recent language standard, or the benefits of those
recent standards. (Which is not to say that they bring _only_
benefits; there _are_ missteps.)

Second, the topic is running compilers capable of compiling the
current version of the language. The universe of interesting
software written in e.g. C is large; much of that requires at
least a C89 compiler; many more of it requires C99, C11 and C23
is on the horizon. By restricting myself to a K&R compiler, I'm
restricting myself to an ever-smaller subset of that universe.
For example, I have an emulated VAX running 4.3BSD. I wanted a
"modern" shell for that; I'm stuck with an ancient version of
tcsh from the previous century that could compile on that
ancient system. Don't get me wrong, it's fun to noodle around
on, but I wouldn't consider that acceptable for serious work in
this day and age.

Third and finally, warnings themselves can be overly aggressive
or misleading. For example, `gcc` has a warning if it detects
that one is calling `strncpy` in such a way that the entire
that the length argument is exactly the size of the destination
argument. This is because people don't understand the semantics
of `strncpy` and often get it wrong in such a way that they may
not NUL-terminate the destination. But the warning is in some
sense too aggressive, and precludes cases where either a) the
programmer _actually_ wants that behavior (for example, they may
be filling in a fixed-length field of some data structure that
might be written to a storage device, or copied over a network,
or otherwise used in some way where the notion of a "C string"
isn's appropriate or desired) or b) they may use some other
common idiom to ensure proper termination:

char dst[128];
strncpy(dst, src, sizeof(dst));
dst[sizeof(dst) - 1] = '\0';

etc. (Of course, the real solution here is to use a more
appropriate function; perhaps `strlcpy`:
https://www.sudo.ws/todd/papers/strlcpy.html).

Anyway, the point is, not all warnings are equally valuable. In
the GCC `strncpy` case, the cure to silence the warning may be
worse than the disease.

>>> As for the other languages. I run the same Fortran that was in
>>> use on everything from minis to mainframes. Full Pascal on both
>>> the Z80 and 6809. Same COBOL that ran on Primes, Univac 1100, RSX,
>>> RSTS, and even VMS. And a version of BASIC on the 6809 that is
>>> far beyond the BASIC that came out on the PC years later. And APL
>>> by its very nature is a perfect fit for these systems. There were
>>> a number of other languages, PILOT, Smalltalk, Lisp etc. but they
>>> weren't really any more successful on bigger machines.
>>>
>>> I wonder how much of this notion that small systems aren't useful
>>> for anything but playing games contributed to companies like DEC
>>> missing the boat when the micro world came along.
>>
>> You can certainly do all kinds of useful stuff on small systems,
>> but in this day and age it begs the question: why? Aside from
>> an interesting academic exercise, I don't much see the point
>> of a hosted environment on a z80 or 6809, particularly when a
>> Raspberry Pi Zero costs $5 or something and gives you so much
>> more. Use those devices as a _target_ platform for something?
>> Sure. But a host? Why bother?
>
>Because I already have them. Because I like nostalgia. Other
>reasons I'm sure.

So, an interesting academic exercise. :-)

>Oh, and I use the Pi and Arduinos as well.
>But they just aren't as much fun.

That's fair. I run a simulated CDC cyber 6600, a bunch of pr1me
stuff, a couple of VAXen and PDP-11's running Unix, TOPS-20,
Multics, Plan 9 etc. It's more fun than a cookie-cutter
Raspberry Pi running Linux. But it's also important to be aware
of the limitations of those things; I do that for fun, but for
serious work I look to modernity for practical reasons.

>Lately I have been thinking
>about tasking another look at Amoeba. Imagine what could be
>done with an Amoeba cluster of Pi's. :-)

In seriousness? Amoeba was an interesting research system 30
years ago. These days, I'd think a cluster of Pi's running Plan
9 would be more interesting (note that Sape Mullender went to
Bell Labs and worked on plan9 after working on Amoeba).

- Dan C.

On 2022-03-23, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <t1fpab$v69$1@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>It seems that everyone falls back to C interface mode when trying
>>to export functions for use by another language. A quick look around
>>seems to show that Rust does the same.
>
> I suppose that if one's definition of a well-defined ABI is what
> you are calling a "C interface mode" that's true, but most ABIs
> are language-independent.
>

It's at this point that I mention many languages directly call this a
C interface mode, including in the syntax that they provide to achieve
this... :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/24/22 08:42, Dan Cross wrote:
>
>
> In seriousness? Amoeba was an interesting research system 30
> years ago. These days, I'd think a cluster of Pi's running Plan
> 9 would be more interesting (note that Sape Mullender went to
> Bell Labs and worked on plan9 after working on Amoeba).

We ran both Amoeba at the University. Had a couple of grad
students do their thesis on it. Very impressive to watch the
cluster move jobs around based on available resources. Was
disappointed when all the work on it stopped for no apparent
reason other than, in typical academic fashion, people tired
of it. I think it had great potential and I think technology
has reached a point where it would be a real asset. A rack
of Pi's occupies a lot less space and consumes a lot less
energy than racks of Sparcs. :-)

We did Plan9 as well. I think I still have all the original
software and manuals from it. While interesting I never saw
the capabilities in it that Amoeba had. Just looked like another
(stranger!) version of Bell Labs Unix. I certainly didn't see
the support for parallelization in Plan9 that I saw in Amoeba.
Might be interesting to take another look at that, too.

Your list of older systems was impressive. Mine matches most
of it. I still do real PDP-11's, real VAX, Sparc, and emulated
I do PDP-11's VAX and Pr1me. (I used to maintain OS and software
on a bunch of 850's and always liked it, even with its quirks.)
But, as you saw, I also do a lot of older small systems. I have
all of the TRS-80 models. Some SBC CP/M machines. And, like
everyone :-) piles of PC's running pretty much anything you can
run on them. It keeps me busy as I am unlikely to make the cut
on anyone's resume search at my age. :-)

bill

On 3/24/2022 9:08 AM, Simon Clubley wrote:
> On 2022-03-23, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t1fpab$v69$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> It seems that everyone falls back to C interface mode when trying
>>> to export functions for use by another language. A quick look around
>>> seems to show that Rust does the same.
>>
>> I suppose that if one's definition of a well-defined ABI is what
>> you are calling a "C interface mode" that's true, but most ABIs
>> are language-independent.
>
> It's at this point that I mention many languages directly call this a
> C interface mode, including in the syntax that they provide to achieve
> this... :-)

True.

But it really isn't a C thing - it is a calling convention thing.

If we take Rust as an example then you can use:

extern "C"

but you cal also use:

extern "stdcall"
extern "cdecl"
extern "system"
extern "aapcs"
etc.

Arne

On 3/23/2022 3:31 PM, John Dallman wrote:
> In article <t1fpab$v69$1@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>> It would be nice to have a richer interface standard that handles
>> calling between both OO and procedural languages natively ...
>
> The difficulty there is the varying ways in which OO access to
> objects/classes/entities is implemented.
>
> The two environments I know of where calling between several OO languages
> is supported are JVM and .NET. In both cases, languages whose usual way
> of doing OO is different from Java and C#, respectively, tend to have to
> be bent into shape.

Overall I think they work pretty good.

Of course there are some language limitations, but usually less
than VMS calling convention for procedural where some languages
are also missing some features.

Opinion based on:

JVM: Java, Kotlin, Scala, Groovy, Python, JavaScript, PHP, Ruby

CLR: C#, VB.NET, F#, Python, JavaScript, PHP, Ruby, Java

Arne

On 3/23/2022 2:37 PM, Simon Clubley wrote:
> On 2022-03-22, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 3/22/22 14:38, Simon Clubley wrote:
>>>
>>> BTW #2, you can only easily call C++ code from a non-C++ program by
>>> providing a C interface in the C++ library so you are back to using
>>> C as an interface language even with C++...
>>
>> Once again, languages don't define calling sequences, compilers do.
>
> Even ignoring the other issues, the nature of C++ means that name
> mangling is a real problem if you try to directly call C++ code from
> a non-C++ language.

Disabling name mangling/decorating is a must.

But even though it is called C interface then it does not
have anything to do with C.

Arne

In article <t1hqgd$c77$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-03-23, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t1fpab$v69$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>It seems that everyone falls back to C interface mode when trying
>>>to export functions for use by another language. A quick look around
>>>seems to show that Rust does the same.
>>
>> I suppose that if one's definition of a well-defined ABI is what
>> you are calling a "C interface mode" that's true, but most ABIs
>> are language-independent.
>>
>
>It's at this point that I mention many languages directly call this a
>C interface mode, including in the syntax that they provide to achieve
>this... :-)

Again, using the calling convention and structure layouts is
still qualitatively different than using C. The ABI gives you a
set of guarantees that you can program to, not the language; the
language at that point is irrelevant.

Further, for instance the System V ABI for x86_64 gives some
flexibility for languages with richer semantics than C. For
example, I see no reason why a language could not represent a
pair type as a small structure of two elements. Provided those
elements each fit within 64 bits, I imagine that such a tuple
could be returned in two registers (%rax, %rdx); nothing in the
ABI seems to preclude that, though it's clearly not something
one can do in C, as C doesn't support tuples.

- Dan C.

In article <623cb7a5$0$694$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 3/24/2022 9:08 AM, Simon Clubley wrote:
>> On 2022-03-23, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> In article <t1fpab$v69$1@dont-email.me>,
>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>> It seems that everyone falls back to C interface mode when trying
>>>> to export functions for use by another language. A quick look around
>>>> seems to show that Rust does the same.
>>>
>>> I suppose that if one's definition of a well-defined ABI is what
>>> you are calling a "C interface mode" that's true, but most ABIs
>>> are language-independent.
>>
>> It's at this point that I mention many languages directly call this a
>> C interface mode, including in the syntax that they provide to achieve
>> this... :-)
>
>True.
>
>But it really isn't a C thing - it is a calling convention thing.
>
>If we take Rust as an example then you can use:

Here's a small example in Rust of calling into assembler:

: spitfire; pwd
/home/cross/demo
: spitfire; cat src/incr.S
..text
..globl incr
incr:
MOVQ %rdi, %rax
INCQ %rax
RET
: spitfire; cat src/main.rs
std::arch::global_asm!(include_str!("incr.S"), options(att_syntax));

extern {
fn incr(i: u64) -> u64;
}

fn main() {
println!("incr(5) = {}", unsafe { incr(5) });
} : spitfire; cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target/debug/demo`
incr(5) = 6
: spitfire;

Here's an example of assembler calling into Rust, including
calling via a mangled name:

: spitfire; pwd
/home/cross/demo2
: spitfire; cat src/caller.S
..text
..globl trampoline, you
trampoline:
JMP you
UD2
: spitfire; cat src/main.rs
#![feature(asm_sym)]

std::arch::global_asm!(include_str!("caller.S"), options(att_syntax));

extern {
fn trampoline(a: i32, b: i32) -> i32;
}

#[no_mangle]
pub extern fn you(a: i32, b: i32) -> i32 {
a + b
}

pub extern fn mangled(a: i32, b: i32) -> i32 {
a + b
}

fn main() {
println!("trampoline(1, 2) = {}", unsafe { trampoline(1, 2) });
let s: i32;
unsafe {
std::arch::asm!(
r#"movl {a:e}, %edi;
movl {b:e}, %esi;
call {mangled};
movl %eax, {s:e}"#,
a = in(reg) 1, b = in(reg) 2, s = out(reg) s,
mangled = sym mangled, options(att_syntax));
}
println!("a = {}", s);
} : spitfire; cargo +nightly run
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target/debug/demo2`
trampoline(1, 2) = 3
a = 3
: spitfire;

Note the inline assembler snippet showing that I can, in fact,
work with mangled symbols. Inspection of the generated object
file shows this to be true:

---BEGIN SNIPPET---
let s: i32;
unsafe {
std::arch::asm!(
487042: 89 cf mov %ecx,%edi
487044: 89 d6 mov %edx,%esi
487046: e8 35 ff ff ff call 486f80 <_ZN5demo27mangled17h46416679b8830bf3E>
48704b: 89 c0 mov %eax,%eax
48704d: 89 45 bc mov %eax,-0x44(%rbp)
call {mangled};
movl %eax, {s:e}"#,
a = in(reg) 1, b = in(reg) 2, s = out(reg) s,
mangled = sym mangled, options(att_syntax));
}
println!("a = {}", s);
---END SNIPPET---

If I dump that same snippet with name demangling, one sees
something intelligible:

---BEGIN SNIPPET---
let s: i32;
unsafe {
std::arch::asm!(
487042: 89 cf mov %ecx,%edi
487044: 89 d6 mov %edx,%esi
487046: e8 35 ff ff ff call 486f80 <demo2::mangled>
48704b: 89 c0 mov %eax,%eax
48704d: 89 45 bc mov %eax,-0x44(%rbp)
call {mangled};
movl %eax, {s:e}"#,
a = in(reg) 1, b = in(reg) 2, s = out(reg) s,
mangled = sym mangled, options(att_syntax));
}
println!("a = {}", s);
---END SNIPPET---

There is not a single line of C in this example.

Of course, all of this works because the name mangling algorithm
is well-specified.

- Dan C.

On 3/25/2022 9:16 AM, Dan Cross wrote:
> In article <623cb7a5$0$694$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 3/24/2022 9:08 AM, Simon Clubley wrote:
>>> On 2022-03-23, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>> In article <t1fpab$v69$1@dont-email.me>,
>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>>> It seems that everyone falls back to C interface mode when trying
>>>>> to export functions for use by another language. A quick look around
>>>>> seems to show that Rust does the same.
>>>>
>>>> I suppose that if one's definition of a well-defined ABI is what
>>>> you are calling a "C interface mode" that's true, but most ABIs
>>>> are language-independent.
>>>
>>> It's at this point that I mention many languages directly call this a
>>> C interface mode, including in the syntax that they provide to achieve
>>> this... :-)
>>
>> True.
>>
>> But it really isn't a C thing - it is a calling convention thing.
>>
>> If we take Rust as an example then you can use:
>
> Here's a small example in Rust of calling into assembler:

> Here's an example of assembler calling into Rust, including
> calling via a mangled name:

> .text
> .globl trampoline, you
> trampoline:
> JMP you
> UD2

> #[no_mangle]
> pub extern fn you(a: i32, b: i32) -> i32 {
> a + b
> }
>
> pub extern fn mangled(a: i32, b: i32) -> i32 {
> a + b
> }

> fn main() {
> println!("trampoline(1, 2) = {}", unsafe { trampoline(1, 2) });
> let s: i32;
> unsafe {
> std::arch::asm!(
> r#"movl {a:e}, %edi;
> movl {b:e}, %esi;
> call {mangled};
> movl %eax, {s:e}"#,
> a = in(reg) 1, b = in(reg) 2, s = out(reg) s,
> mangled = sym mangled, options(att_syntax));
> }
> println!("a = {}", s);
> }

> Note the inline assembler snippet showing that I can, in fact,
> work with mangled symbols. Inspection of the generated object
> file shows this to be true:

> If I dump that same snippet with name demangling, one sees
> something intelligible:

> 487046: e8 35 ff ff ff call 486f80 <demo2::mangled>

> There is not a single line of C in this example.
>
> Of course, all of this works because the name mangling algorithm
> is well-specified.

If I read that code correctly then it works because the
std::arch::asm ... mangled = sym mangled knows what to do.

Which is not general language interop.

Arne

In article <623dc61c$0$702$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 3/25/2022 9:16 AM, Dan Cross wrote:
>[snip]
>> Of course, all of this works because the name mangling algorithm
>> is well-specified.
>
>If I read that code correctly then it works because the
>std::arch::asm ... mangled = sym mangled knows what to do.
>
>Which is not general language interop.

It "knows what to do" because the name mangling algorithm is
well-specified by a generic ABI, which is the point:

https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling

Rust provides a convenient mechanism to make this trivial.

- Dan C.