Does C# qualify as a Microsoft proprietary language? Or are there implementations on OSes other than Windows (and compilers, either
open source or available from other vendors)?
On Sun, 04 Jan 2026 19:41:11 GMT, Charlie Gibbs wrote:
Does C# qualify as a Microsoft proprietary language? Or are there
implementations on OSes other than Windows (and compilers, either
open source or available from other vendors)?
The only implementation I?m aware of is Microsoft?s one built on top
of Dotnet.
Dotnet itself is supposedly open-source and portable to some degree
now. There are reports of it running on Linux.
On 1/4/26 16:18, Lawrence D?Oliveiro wrote:
On Sun, 04 Jan 2026 19:41:11 GMT, Charlie Gibbs wrote:
Does C# qualify as a Microsoft proprietary language? Or are there
implementations on OSes other than Windows (and compilers, either
open source or available from other vendors)?
The only implementation I?m aware of is Microsoft?s one built on top
of Dotnet.
Dotnet itself is supposedly open-source and portable to some degree
now. There are reports of it running on Linux.
That would be very end-around ...
Maybe just to forget C# ... CPP is good enough.
Actually, don't even like CPP ... plain 'C' has
so far met all my needs.
Lawrence D?Oliveiro wrote:
Charlie Gibbs wrote:
Does C# qualify as a Microsoft proprietary language? Or are there
implementations on OSes other than Windows (and compilers, either open
source or available from other vendors)?
The only implementation I?m aware of is Microsoft?s one built on top
of Dotnet.
Dotnet itself is supposedly open-source and portable to some degree
now. There are reports of it running on Linux.
It definitely runs on Linux and is easily installed with dnf or apt. GUIs have been problematic but console and ASP.NET workks fine.
https://dotnet.microsoft.com/en-us/apps/aspnet
This isn't Ballmer's Microsoft.
plain 'C' has ÿ so far met all my needs.
The Pico SDK documentation talks about C/C++ but I
haven't seen C++ being used much in the examples.
Anyway C++ is handy in small doses.
On Sun, 04 Jan 2026 19:41:11 GMT, Charlie Gibbs wrote:
Does C# qualify as a Microsoft proprietary language? Or are there
implementations on OSes other than Windows (and compilers, either
open source or available from other vendors)?
The only implementation I?m aware of is Microsoft?s one built on top
of Dotnet.
Dotnet itself is supposedly open-source and portable to some degree
now. There are reports of it running on Linux.
On Sun, 4 Jan 2026 19:04:14 -0500, c186282 wrote:
<brevsnip>
Actually, don't even like CPP ... plain 'C' has so far met all my
needs.
I was thinking about C++ on my walk today. Arduino sketches and other MCU SDKs refer to C/C++.
#include <nRF24L01.h>
#include <RF24.h>
#define led 12
RF24 radio(7, 8);
const byte addresses[][6] = {"00001", "00002"};
int angleValue = 0;
boolean buttonState = 0;
<snip>
Anyway C++ is handy in small doses.
On 05/01/2026 03:55, rbowman wrote:
The Pico SDK documentation talks about C/C++ but II tend to avoid the examples where it is being used.
haven't seen C++ being used much in the examples.
Anyway C++ is handy in small doses.
I've not found it at all necessary, ever.
On Sun, 4 Jan 2026 19:04:14 -0500, c186282 wrote:
On 1/4/26 16:18, Lawrence D?Oliveiro wrote:
On Sun, 04 Jan 2026 19:41:11 GMT, Charlie Gibbs wrote:
Does C# qualify as a Microsoft proprietary language? Or are there
implementations on OSes other than Windows (and compilers, either open >>>> source or available from other vendors)?
The only implementation I?m aware of is Microsoft?s one built on top of
Dotnet.
Dotnet itself is supposedly open-source and portable to some degree
now. There are reports of it running on Linux.
That would be very end-around ...
Maybe just to forget C# ... CPP is good enough.
Actually, don't even like CPP ... plain 'C' has so far met all my
needs.
I was thinking about C++ on my walk today. Arduino sketches and other MCU SDKs refer to C/C++.
#include <nRF24L01.h>
#include <RF24.h>
#define led 12
RF24 radio(7, 8);
const byte addresses[][6] = {"00001", "00002"};
int angleValue = 0;
boolean buttonState = 0;
void setup() {
Serial.begin(9600);
radio.begin();
radio.openWritingPipe(addresses[1]);
radio.openReadingPipe(1, addresses[0]);
radio.setPALevel(RF24_PA_MIN);
}
Obviously when you instantiate the RF24 objects and start calling class methods that will use parameters passed in to the constructor, you're in
C++ land. However for the most part it's 'C with Classes' and very seldom
has to get into the C++ esoterica.
Arduino simplifies it by magically creating setup() and loop() without
the boilerplate. The Pico SDK documentation talks about C/C++ but I
haven't seen C++ being used much in the examples.
Anyway C++ is handy in small doses.
You can really blame Microsoft for creating MFC; they had to wrap their C API in something. You can blame them for DDE/OLE/COM, the ATl, and
adopting Hungarian notation.
The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted with "Hell yeah!" rather than "What CS PhD dreamed this crap up?"
C#/dotnet ... I'm uncomfortable seeing such
heavily M$ solutions used in Linux. I still
have this vision of M$ lawyers waiting until
enough Linux stuff is writ using their stuff
and then POUNCING.
On 05/01/2026 17:48, rbowman wrote:
The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted with >> "Hell yeah!" rather than "What CS PhD dreamed this crap up?"
Spot on.
C is enough to do the job and simple to learn. Why complicate shit?
On 2026-01-05, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 05/01/2026 17:48, rbowman wrote:
The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted with >>> "Hell yeah!" rather than "What CS PhD dreamed this crap up?"
Spot on.
C is enough to do the job and simple to learn. Why complicate shit?
Let me guess: so companies can sell you a new compiler every year,
plus courses in how to use the new shit.
Let me guess: so companies can sell you a new compiler every year,
plus courses in how to use the new shit.
On 2026-01-05, rbowman <bowman@montana.com> wrote:
You can really blame Microsoft for creating MFC; they had to wrap their C >> API in something. You can blame them for DDE/OLE/COM, the ATl, and
adopting Hungarian notation.
(I assume you meant "can't really blame" at the beginning there?)
Time to dip into the quotes file again:
Hungarian Notation is the tactical nuclear weapon of source code
obfuscation techniques.
-- Roedy Green
On 2026-01-05, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 05/01/2026 17:48, rbowman wrote:
The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted with >>> "Hell yeah!" rather than "What CS PhD dreamed this crap up?"
Spot on.
C is enough to do the job and simple to learn. Why complicate shit?
Let me guess: so companies can sell you a new compiler every year,
plus courses in how to use the new shit.
Niklas Karlsson wrote this post by blinking in Morse code:
On 2026-01-05, rbowman <bowman@montana.com> wrote:
You can really blame Microsoft for creating MFC; they had to wrap their C >>> API in something. You can blame them for DDE/OLE/COM, the ATl, and
adopting Hungarian notation.
(I assume you meant "can't really blame" at the beginning there?)
Time to dip into the quotes file again:
Hungarian Notation is the tactical nuclear weapon of source code
obfuscation techniques.
-- Roedy Green
Agreed. The only warts I use are:
m_ A class member. But I often make an accessor function
without the "m_"
sm_ A static class member.
c_ A constant, not in a class..
Lawrence D?Oliveiro wrote this post by blinking in Morse code:
On Sun, 04 Jan 2026 19:41:11 GMT, Charlie Gibbs wrote:
Does C# qualify as a Microsoft proprietary language? Or are there
implementations on OSes other than Windows (and compilers, either
open source or available from other vendors)?
The only implementation I?m aware of is Microsoft?s one built on top
of Dotnet.
Dotnet itself is supposedly open-source and portable to some degree
now. There are reports of it running on Linux.
<https://learn.microsoft.com/en-us/dotnet/core/install/linux>
Install .NET on Linux
Also:
<https://github.com/mono/mono>
On 1/5/26 22:25, Chris Ahlstrom wrote:
Niklas Karlsson wrote this post by blinking in Morse code:
On 2026-01-05, rbowman <bowman@montana.com> wrote:
You can really blame Microsoft for creating MFC; they had to wrap their C >>>> API in something. You can blame them for DDE/OLE/COM, the ATl, and
adopting Hungarian notation.
(I assume you meant "can't really blame" at the beginning there?)
Time to dip into the quotes file again:
Hungarian Notation is the tactical nuclear weapon of source code
obfuscation techniques.
-- Roedy Green
Agreed. The only warts I use are:
m_ A class member. But I often make an accessor function
without the "m_"
sm_ A static class member.
c_ A constant, not in a class..
I thought that all stopped 15-20 years ago when IDEs introduced auto colouring.
On 05/01/2026 17:48, rbowman wrote:
The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted
with
"Hell yeah!" rather than "What CS PhD dreamed this crap up?"
Spot on.
C is enough to do the job and simple to learn. Why complicate shit?
On 2026-01-05 19:09, The Natural Philosopher wrote:
On 05/01/2026 17:48, rbowman wrote:
The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted
with
"Hell yeah!" rather than "What CS PhD dreamed this crap up?"
Spot on.
C is enough to do the job and simple to learn. Why complicate shit?
My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a proper language would catch.
That was around 1991.
He knew. He participated in some study tasked by the Canadian government
to study C compilers, but he could not talk about what they wrote.
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C.
<interjection>
C++ (and some other languages)
have exceptions, C do not have them.
</interjection>
There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.
There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.
Waldek Hebisch wrote this post by blinking in Morse code:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C.
<interjection>
C++ (and some other languages)
have exceptions, C do not have them.
What about setjmp()/longjmp() ?
On 2026-01-05 19:09, The Natural Philosopher wrote:
On 05/01/2026 17:48, rbowman wrote:
The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted
with
"Hell yeah!" rather than "What CS PhD dreamed this crap up?"
Spot on.
C is enough to do the job and simple to learn. Why complicate shit?
My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a proper language would catch.
That was around 1991.
He knew.
He participated in some study tasked by the Canadian government
to study C compilers, but he could not talk about what they wrote.
Waldek Hebisch wrote this post by blinking in Morse code:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C.
<interjection>
C++ (and some other languages)
have exceptions, C do not have them.
What about setjmp()/longjmp() ?
On 06/01/2026 16:12, Chris Ahlstrom wrote:
Waldek Hebisch wrote this post by blinking in Morse code:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C.
<interjection>
C++ (and some other languages)
have exceptions, C do not have them.
What about setjmp()/longjmp() ?
Exactly. The problem with making high level 'features' in a language is >people then don't see how they actually work.
One of the worst features of C libs is malloc() and free() where the >underlying mechanism is opaque.
auto allocation and garbage collection is even worse.
Also operator overloading and weak typing.
You simply do not know where you are.
It's all fearfully clever ins a smart alec sort of way but it makes for
a lot of problems downstream...
In article <10jjc9s$3uhtk$1@dont-email.me>,
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
Waldek Hebisch wrote this post by blinking in Morse code:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C.
<interjection>
C++ (and some other languages)
have exceptions, C do not have them.
What about setjmp()/longjmp() ?
Not at all the same thing. `setjmp`/`longjmp` are about
non-local flows of control; exceptions are about non-local
passing of values.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10jjc9s$3uhtk$1@dont-email.me>,
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
Waldek Hebisch wrote this post by blinking in Morse code:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C.
<interjection>
C++ (and some other languages)
have exceptions, C do not have them.
What about setjmp()/longjmp() ?
Not at all the same thing. `setjmp`/`longjmp` are about
non-local flows of control; exceptions are about non-local
passing of values.
However, in many real world situations, [sig]setjump and
[sig]longjmp can be used to emulate exceptions.
I have a C++ application that models a computer (Burroughs V380
et alia). The thread that models each processor (cpu) uses
longjmp whenever a condition is encountered that would have
been signaled as a fault on the real cpu. The processor code
doesn't do dynamic memory allocation; and the fault code is
stored in the processor class before the longjmp call.
I once tried replacing setjmp/longjmp with C++ exceptions which
led to a 20% reduction in simulated CPU performance (as measured
by the time to compile a COBOL program).
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.
There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.
But it CAN be much more friendly and/or
tuned to a particular area of interest
or preferred programming style.
In article <84c7R.819121$PGrb.160843@fx10.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10jjc9s$3uhtk$1@dont-email.me>,
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
Waldek Hebisch wrote this post by blinking in Morse code:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C.
<interjection>
C++ (and some other languages)
have exceptions, C do not have them.
What about setjmp()/longjmp() ?
Not at all the same thing. `setjmp`/`longjmp` are about
non-local flows of control; exceptions are about non-local
passing of values.
However, in many real world situations, [sig]setjump and
[sig]longjmp can be used to emulate exceptions.
Yes, I said just that. :-)
I have a C++ application that models a computer (Burroughs V380
et alia). The thread that models each processor (cpu) uses
longjmp whenever a condition is encountered that would have
been signaled as a fault on the real cpu. The processor code
doesn't do dynamic memory allocation; and the fault code is
stored in the processor class before the longjmp call.
I once tried replacing setjmp/longjmp with C++ exceptions which
led to a 20% reduction in simulated CPU performance (as measured
by the time to compile a COBOL program).
Huh. Interesting. I wonder why...possibly to run a bunch of
nop destructors?
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
On 1/6/26 07:16, Waldek Hebisch wrote:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.
There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.
You give it a file in whatever lang, it produces
a file in 'C' and compiles that.
No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently
AFAIK you can remove C compiler binary and other compilers in
gcc will still work.
So, I'll basically
stick with my 'translator' def. And if 'C' does not
'natively support' something you can FAKE it with code,
not really anything you CAN'T do with 'C'.
A I wrote, you can use "via C" translators, but results are
not so good as with dedicated compilers, that is why gcc
contains separate compilers.
By 'compiler' I mean "source in -> (agitating sounds) ->
binary executable out.
By that definition gcc does _not_ contain a C compiler:
gcc generates assembly and then assembler and linker produce
final executable.
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
On 1/6/26 07:16, Waldek Hebisch wrote:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.
There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.
You give it a file in whatever lang, it produces
a file in 'C' and compiles that.
No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently
AFAIK you can remove C compiler binary and other compilers in
gcc will still work.
So, I'll basically
stick with my 'translator' def. And if 'C' does not
'natively support' something you can FAKE it with code,
not really anything you CAN'T do with 'C'.
A I wrote, you can use "via C" translators, but results are
not so good as with dedicated compilers, that is why gcc
contains separate compilers.
By 'compiler' I mean "source in -> (agitating sounds) ->
binary executable out.
By that definition gcc does _not_ contain a C compiler:
gcc generates assembly and then assembler and linker produce
final executable. Things are more complicated when you use
LTO, because "linker" in this case actially is doing large part
of compiler work and optimized code before producing final
executable. But non-LTO compilation works via assembly.
I think there are still a few FORTRAN compilers out
there for Linux, maybe COBOL too. There's at least
one forth IDE/compiler. Digital Mars makes 'C' and
'D' compilers. GCC is not the alpha and omega
of software development.
But it CAN be much more friendly and/or
tuned to a particular area of interest
or preferred programming style.
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
On 1/6/26 07:16, Waldek Hebisch wrote:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.
There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.
You give it a file in whatever lang, it produces
a file in 'C' and compiles that.
No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently
On 1/6/26 07:16, Waldek Hebisch wrote:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.
There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.
You give it a file in whatever lang, it produces
a file in 'C' and compiles that.
On Tue, 6 Jan 2026 08:03:13 +0000, Pancho wrote:
C# is a lovely language, but isn't different enough from Java to make it
worthwhile doing something with much less online support when using
Linux.
C# is what Java should have been, I had hopes for Java in the late '90s
that were dashed when it became bloated and slow.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <84c7R.819121$PGrb.160843@fx10.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10jjc9s$3uhtk$1@dont-email.me>,
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
Waldek Hebisch wrote this post by blinking in Morse code:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C.
<interjection>
C++ (and some other languages)
have exceptions, C do not have them.
What about setjmp()/longjmp() ?
Not at all the same thing. `setjmp`/`longjmp` are about
non-local flows of control; exceptions are about non-local
passing of values.
However, in many real world situations, [sig]setjump and
[sig]longjmp can be used to emulate exceptions.
Yes, I said just that. :-)
I have a C++ application that models a computer (Burroughs V380
et alia). The thread that models each processor (cpu) uses
longjmp whenever a condition is encountered that would have
been signaled as a fault on the real cpu. The processor code
doesn't do dynamic memory allocation; and the fault code is
stored in the processor class before the longjmp call.
I once tried replacing setjmp/longjmp with C++ exceptions which
led to a 20% reduction in simulated CPU performance (as measured
by the time to compile a COBOL program).
Huh. Interesting. I wonder why...possibly to run a bunch of
nop destructors?
A large component of the overhead was the code generated in every
function to handle unwinding during exception processing.
When
using setjmp/longjmp, I compiled with the following options so
it wouldn't generate the unwind code:
GXXFLAGS = -mno-red-zone
GXXFLAGS += -fno-strict-aliasing
GXXFLAGS += -fno-stack-protector
GXXFLAGS += -fno-exceptions
GXXFLAGS += -Wall
GXXFLAGS += -mtune=native
On 1/6/26 07:16, Waldek Hebisch wrote:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
ÿÿ Hmm ... look at all the GNU 'compilers' -
ÿÿ FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
ÿÿ G++, even Algol-68. None are 'compilers'
ÿÿ per-se, but to-'C' TRANSLATORS. So, 'C',
ÿÿ pretty much All Are One And One Is All.
No.ÿ Compiler as first stage translate given language to a
common representation.ÿ This representatiton is different
than C.ÿ Ada and GNU Pascal have parametrized types, there
is nothing like that in C.ÿ C++ (and some other languages)
have exceptions, C do not have them.ÿ There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo.ÿ During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.
There were/are compilers that work by translating to C.ÿ But
this has limitations: generated code typically is worse because
language specific information is lost in translation.ÿ Error
reporting is worse because translator is not doing as many
analyzes as gcc do.ÿ For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.
ÿ You give it a file in whatever lang, it produces
ÿ a file in 'C' and compiles that. So, I'll basically
ÿ stick with my 'translator' def. And if 'C' does not
ÿ 'natively support' something you can FAKE it with code,
ÿ not really anything you CAN'T do with 'C'.
ÿ By 'compiler' I mean "source in -> (agitating sounds) ->
ÿ binary executable out.
ÿ I think there are still a few FORTRAN compilers out
ÿ there for Linux, maybe COBOL too. There's at least
ÿ one forth IDE/compiler. Digital Mars makes 'C' and
ÿ 'D' compilers. GCC is not the alpha and omega
ÿ of software development.
ÿÿ But it CAN be much more friendly and/or
ÿÿ tuned to a particular area of interest
ÿÿ or preferred programming style.
On 1/6/26 14:24, c186282 wrote:
On 1/6/26 07:16, Waldek Hebisch wrote:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
ÿÿ Hmm ... look at all the GNU 'compilers' -
ÿÿ FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
ÿÿ G++, even Algol-68. None are 'compilers'
ÿÿ per-se, but to-'C' TRANSLATORS. So, 'C',
ÿÿ pretty much All Are One And One Is All.
No.ÿ Compiler as first stage translate given language to a
common representation.ÿ This representatiton is different
than C.ÿ Ada and GNU Pascal have parametrized types, there
is nothing like that in C.ÿ C++ (and some other languages)
have exceptions, C do not have them.ÿ There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo.ÿ During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.
There were/are compilers that work by translating to C.ÿ But
this has limitations: generated code typically is worse because
language specific information is lost in translation.ÿ Error
reporting is worse because translator is not doing as many
analyzes as gcc do.ÿ For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.
ÿ You give it a file in whatever lang, it produces
ÿ a file in 'C' and compiles that. So, I'll basically
ÿ stick with my 'translator' def. And if 'C' does not
ÿ 'natively support' something you can FAKE it with code,
ÿ not really anything you CAN'T do with 'C'.
ÿ By 'compiler' I mean "source in -> (agitating sounds) ->
ÿ binary executable out.
ÿ I think there are still a few FORTRAN compilers out
ÿ there for Linux, maybe COBOL too. There's at least
ÿ one forth IDE/compiler. Digital Mars makes 'C' and
ÿ 'D' compilers. GCC is not the alpha and omega
ÿ of software development.
ÿÿ But it CAN be much more friendly and/or
ÿÿ tuned to a particular area of interest
ÿÿ or preferred programming style.
Iron Spring PL/I compiles directly to binary. It can produce assembler >output, but only as a by-product of generating the object file. I have >occasionally thought of trying to make it another front-end for GCC. As
I understand it, GCC compiles to an intermediate language, not to C.
On 2026-01-06, Waldek Hebisch <antispam@fricas.org> wrote:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
On 1/6/26 07:16, Waldek Hebisch wrote:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.
There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.
You give it a file in whatever lang, it produces
a file in 'C' and compiles that.
No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently
Still, Bjarne Stroustrup's first implementation of C++
was a program called cfront, which translated C++ to C.
In article <fzf7R.805815$i%aa.272881@fx12.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <84c7R.819121$PGrb.160843@fx10.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10jjc9s$3uhtk$1@dont-email.me>,
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
Waldek Hebisch wrote this post by blinking in Morse code:
In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
<snip>
Hmm ... look at all the GNU 'compilers' -
FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
G++, even Algol-68. None are 'compilers'
per-se, but to-'C' TRANSLATORS. So, 'C',
pretty much All Are One And One Is All.
No. Compiler as first stage translate given language to a
common representation. This representatiton is different
than C. Ada and GNU Pascal have parametrized types, there
is nothing like that in C.
<interjection>
C++ (and some other languages)
have exceptions, C do not have them.
What about setjmp()/longjmp() ?
Not at all the same thing. `setjmp`/`longjmp` are about
non-local flows of control; exceptions are about non-local
passing of values.
However, in many real world situations, [sig]setjump and
[sig]longjmp can be used to emulate exceptions.
Yes, I said just that. :-)
I have a C++ application that models a computer (Burroughs V380
et alia). The thread that models each processor (cpu) uses
longjmp whenever a condition is encountered that would have
been signaled as a fault on the real cpu. The processor code
doesn't do dynamic memory allocation; and the fault code is
stored in the processor class before the longjmp call.
I once tried replacing setjmp/longjmp with C++ exceptions which
led to a 20% reduction in simulated CPU performance (as measured
by the time to compile a COBOL program).
Huh. Interesting. I wonder why...possibly to run a bunch of
nop destructors?
A large component of the overhead was the code generated in every
function to handle unwinding during exception processing.
That makes sense; thanks.
When
using setjmp/longjmp, I compiled with the following options so
it wouldn't generate the unwind code:
GXXFLAGS = -mno-red-zone
GXXFLAGS += -fno-strict-aliasing
GXXFLAGS += -fno-stack-protector
GXXFLAGS += -fno-exceptions
GXXFLAGS += -Wall
GXXFLAGS += -mtune=native
Most of those seem irrelevant to generating extra code for stack
unwinding.
These bizarre definitional assertions about what makes something
a "compiler" or not seem to be mostly put forth by people who
have never heard of the concept of "separate compilation" or
"libraries", let alone touched the innards of a compiler. In
particular, this idea that everything must be implemented in a
single program or it's not a "true" compiler is rooted firmly in
ignorance.
On the other hand, a compiler that uses another compiled language
as intermediate code is a strange beast, probably better called a translator.
These bizarre definitional assertions about what makes something
a "compiler" or not seem to be mostly put forth by people who
have never heard of the concept of "separate compilation" or
"libraries", let alone touched the innards of a compiler. In
particular, this idea that everything must be implemented in a
single program or it's not a "true" compiler is rooted firmly in
ignorance.
On the other hand, a compiler that uses another compiled language as intermediate code is a strange beast, probably better called a
translator.
No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently
AFAIK you can remove C compiler binary and other compilers in
gcc will still work.
So, I'll basicallyA I wrote, you can use "via C" translators, but results are
stick with my 'translator' def. And if 'C' does not
'natively support' something you can FAKE it with code,
not really anything you CAN'T do with 'C'.
not so good as with dedicated compilers, that is why gcc
contains separate compilers.
By 'compiler' I mean "source in -> (agitating sounds) ->By that definition gcc does_not_ contain a C compiler:
binary executable out.
gcc generates assembly and then assembler and linker produce
final executable. Things are more complicated when you use
LTO, because "linker" in this case actially is doing large part
of compiler work and optimized code before producing final
executable. But non-LTO compilation works via assembly.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 15 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 40:54:25 |
| Calls: | 188 |
| Files: | 21,502 |
| Messages: | 80,796 |