On 30/01/2022 11:43 pm, John Dallman wrote:
> In article <st4sup$gh9$1@gioia.aioe.org>, maher_rjSPAMLESS@hotmail.com
> (Richard Maher) wrote:
>
>> And if you can program some MACRO then you need a Garbage Collect
>> to cover up your lack of skill in managing memory.
>
> Not really. Programs written in assembly languages tend to have much
> simpler memory management schemes than ones written in high-level
> languages. If the program is at all complex, some memory allocation and
> deallocation macros are usually written, and one can make those complain
> about mismatched allocates and frees.
>
> John
Yeah my bad. Should read "can't"

On 1/30/22 18:23, Simon Clubley wrote:
> On 2022-01-28, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>
>> And which Fortran standard includes "!DEC$ATTRIBUTES ADDRESS64::cy"?
>>
>
> Some programming languages have pragma statements and that is the
> same thing.
>
> $ set response/mode=good_natured
>
> Or are you those people who doesn't like that newfangled Fortran
> stuff such as free-form statements and thinks everyone should
> write Fortran in punched card format ? :-)
>

I'm one of those people who think if you significantly change
a language you should have the courtesy to give it a new name
and not pretend it is an already existing language. :-)

The only real C is that described in the K&R manual.

bill

On 1/30/2022 9:55 PM, Bill Gunshannon wrote:
> On 1/30/22 18:23, Simon Clubley wrote:
>> On 2022-01-28, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>
>>> And which Fortran standard includes "!DEC$ATTRIBUTES ADDRESS64::cy"?
>>>
>>
>> Some programming languages have pragma statements and that is the
>> same thing.
>>
>> $ set response/mode=good_natured
>>
>> Or are you those people who doesn't like that newfangled Fortran
>> stuff such as free-form statements and thinks everyone should
>> write Fortran in punched card format ? :-)
>
> I'm one of those people who think if you significantly change
> a language you should have the courtesy to give it a new name
> and not pretend it is an already existing language.  :-)

Fortran 77 to Fortran 90 could have justified a new name.

Arne

On 1/30/22 19:20, Simon Clubley wrote:
> On 2022-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> And it is not just me.
>>
>> The rust people are rewriting GNU Coreutils (C) in
>> rust.
>>
>> https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022
>>
>
> Let me know when the Rust compiler runs on all the architectures
> that Linux runs on. :-)
>

Let me know when you discover how easy it is to bootstrap
Rust on a new architecture. :-)

bill

On 1/30/2022 9:55 PM, Bill Gunshannon wrote:
> The only real C is that described in the K&R manual.

1st or 2nd edition?

:-)

Arne

On 1/30/22 19:49, Arne Vajhøj wrote:
> On 1/30/2022 7:20 PM, Simon Clubley wrote:
>> On 2022-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> And it is not just me.
>>>
>>> The rust people are rewriting GNU Coreutils (C) in
>>> rust.
>>>
>>> https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022
>>>
>>>
>>
>> Let me know when the Rust compiler runs on all the architectures
>> that Linux runs on. :-)
>
> They are missing some.
>
> Rust supports x86, x86-64, ARM, MIPS, PPC, RISC-V and mainframe.
>
> So they are missing Alpha, PA, Itanium, SPARC and several
> lesser ones.
>
> But who actually runs Linux on one of those?
>

I still run it on a SPARC. If I still had an Alpha I would
probably be running it n that, too. I never have and never
will own an Itanium. But I do still work on a 6809 running
OS-9. I doubt it will ever show up there. And then there
are my PDP-11's and VAXen. :-) Linux isn't the best thing
since sliced bread no matter how many architectures it runs
on.

bill

On 1/30/22 22:01, Arne Vajhøj wrote:
> On 1/30/2022 9:55 PM, Bill Gunshannon wrote:
>> The only real C is that described in the K&R manual.
>
> 1st or 2nd edition?
>
> :-)
>

I still use 1st. :-) It is the version of C that runs on a lot of
the systems I still enjoy working on.

bill

On 31/01/2022 00:22, Simon Clubley wrote:
> On 2022-01-29, Scott Dorsey <kludge@panix.com> wrote:
>>
>> Pascal is pretty limited but makes it hard to shoot yourself in the foot.
>> And most implementations don't use null-terminated strings which are the
>> most serious source of vulnerabilities in C code.
>> --scott
>>
>
> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>
> Simon.
>

VAXELN started life as a "Pascal-like" language system. It wasn't
entirely the same language or toolset as used by VAX Pascal, or the same
language as ISO Pascal.

They were close enough for a lot of purposes, but they weren't the same.

See e.g. the VAXELN Pascal Language Reference Manual at e.g.
http://www.bitsavers.org/pdf/dec/vax/vaxeln/2.0/AA-EU39A-TE_VAXELN_Pascal_Language_Reference_Manual_Mar85.pdf
(other sources doubtless apply):

"VAXELN Pascal is a compatible superset of the
language defined in the International Standards
Organization document ISO DIS 7185. Any program
written in ISO-standard Pascal can be compiled by the
VAXELN Pascal compiler and executed as part of the
system.

However, VAXELN Pascal has been extended to
include data types and operations that support
concurrent programming. It is supported by a highly
optimizing compiler that generates position-
independent, native-mode code. In addition, it is the
primary implementation language of the VAXELN
toolkit itself."

Or for a twenty-page overview see e.g. the VAXELN Technical Overview at
e.g.
http://www.bitsavers.org/pdf/dec/vax/vaxeln/2.0/VAXELN_Technical_Overview_1986.pdf

There's a whole lot more to VAXELN than just ISO Pascal.

Now, where were we?

On 2022-01-31 01:22, Simon Clubley wrote:
> On 2022-01-29, Scott Dorsey <kludge@panix.com> wrote:
>>
>> Pascal is pretty limited but makes it hard to shoot yourself in the foot.
>> And most implementations don't use null-terminated strings which are the
>> most serious source of vulnerabilities in C code.
>> --scott
>>
>
> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...

The problem is that the ISO standard for Pascal is pretty useless. Which
is why every useful Pascal have extensions...
And they are all different...
Which makes everything very non-standard...

But Pascal is definitely not that bad a language. But it has it's warts...

Johnny

On 2022-01-31 01:43, Arne Vajhøj wrote:
> On 1/30/2022 7:19 PM, Simon Clubley wrote:
>> On 2022-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 1/29/2022 1:53 AM, George Cornelius wrote:
>>>>
>>>> Works on Eisner.
>>>>
>>>> $ show sys/noproc
>>>> OpenVMS V8.4-2L2  on node EISNER   29-JAN-2022 [...]
>>>>
>>>> Here's the memory layout synopsis from a linker map:
>>>>
>>>> Virtual memory allocated:                         00010000 0005FFFF
>>>> 00050000 (327680. bytes, 640. pages)
>>>> 64-Bit Virtual memory allocated:                  00000000 00000000
>>>> 00000000
>>>>                                                     80000000
>>>> 80010000 00010000 (65536. bytes, 128. pages)
>>>>
>>>> The example, though, shows too small an allocation to escape 32 bit
>>>> address space.
>>>
>>> I consider 0000000080000000 to be 64 bit space.
>>>
>>> 0000000000000000 - 000000007FFFFFFF is P0 and P1 space
>>> FFFFFFFF80000000 - FFFFFFFFFFFFFFFF is S0 and S1 space
>>> 0000000080000000 and upward is P2 space
>>>
>>
>> I think George's point is that this specific address can be
>> represented in a 32-bit pointer.
>
> It can't.
>
> A 32 bit pointer with the value 80000000 will end up as
> FFFFFFFF80000000.

Since when are pointers considered to be signed and need sign extension?

Johnny

Johnny Billquist schrieb am Montag, 31. Januar 2022 um 09:33:06 UTC+1:
> On 2022-01-31 01:43, Arne Vajhøj wrote:
> > On 1/30/2022 7:19 PM, Simon Clubley wrote:
> >> On 2022-01-29, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >>> On 1/29/2022 1:53 AM, George Cornelius wrote:
> >>>>
> >>>> Works on Eisner.
> >>>>
> >>>> $ show sys/noproc
> >>>> OpenVMS V8.4-2L2 on node EISNER 29-JAN-2022 [...]
> >>>>
> >>>> Here's the memory layout synopsis from a linker map:
> >>>>
> >>>> Virtual memory allocated: 00010000 0005FFFF
> >>>> 00050000 (327680. bytes, 640. pages)
> >>>> 64-Bit Virtual memory allocated: 00000000 00000000
> >>>> 00000000
> >>>> 80000000
> >>>> 80010000 00010000 (65536. bytes, 128. pages)
> >>>>
> >>>> The example, though, shows too small an allocation to escape 32 bit
> >>>> address space.
> >>>
> >>> I consider 0000000080000000 to be 64 bit space.
> >>>
> >>> 0000000000000000 - 000000007FFFFFFF is P0 and P1 space
> >>> FFFFFFFF80000000 - FFFFFFFFFFFFFFFF is S0 and S1 space
> >>> 0000000080000000 and upward is P2 space
> >>>
> >>
> >> I think George's point is that this specific address can be
> >> represented in a 32-bit pointer.
> >
> > It can't.
> >
> > A 32 bit pointer with the value 80000000 will end up as
> > FFFFFFFF80000000.
> Since when are pointers considered to be signed and need sign extension?
>
> Johnny

Johnny Billquist schrieb am Montag, 31. Januar 2022 um 09:33:06 UTC+1:
> On 2022-01-31 01:43, Arne Vajhøj wrote:
> > On 1/30/2022 7:19 PM, Simon Clubley wrote:
> >> On 2022-01-29, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >>> On 1/29/2022 1:53 AM, George Cornelius wrote:
> >>>>
> >>>> Works on Eisner.
> >>>>
> >>>> $ show sys/noproc
> >>>> OpenVMS V8.4-2L2 on node EISNER 29-JAN-2022 [...]
> >>>>
> >>>> Here's the memory layout synopsis from a linker map:
> >>>>
> >>>> Virtual memory allocated: 00010000 0005FFFF
> >>>> 00050000 (327680. bytes, 640. pages)
> >>>> 64-Bit Virtual memory allocated: 00000000 00000000
> >>>> 00000000
> >>>> 80000000
> >>>> 80010000 00010000 (65536. bytes, 128. pages)
> >>>>
> >>>> The example, though, shows too small an allocation to escape 32 bit
> >>>> address space.
> >>>
> >>> I consider 0000000080000000 to be 64 bit space.
> >>>
> >>> 0000000000000000 - 000000007FFFFFFF is P0 and P1 space
> >>> FFFFFFFF80000000 - FFFFFFFFFFFFFFFF is S0 and S1 space
> >>> 0000000080000000 and upward is P2 space
> >>>
> >>
> >> I think George's point is that this specific address can be
> >> represented in a 32-bit pointer.
> >
> > It can't.
> >
> > A 32 bit pointer with the value 80000000 will end up as
> > FFFFFFFF80000000.
> Since when are pointers considered to be signed and need sign extension?
>
> Johnny

I guess pointers are sign extended since the arrival of 64 bit addresses with alpha.
It obviously was felt important that 32 bit pointers are still able to access system space.
For normal user programs this is almost never needed, however.
It would be much more useful to have unsigned pointers and unsigned parameter descriptors.
This would allow access to the first 2 GByte of P2 space via 32 bit pointers.
As a workaround we have quite a lot of pascal routines which explicitly extend the
32 bit pointers passed to them to 64 bits without sign extension.

In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> Fortran and COBOL are not suitable for writing operating system userland
> tools.

Why not?

In article <st7iak$ab6$1@gioia.aioe.org>, Richard Maher <maher_rjSPAMLESS@hotmail.com> writes:
>
>> I've never needed "garbage collection" and I've written some very large and complex
>> products all in Macro!
>
>Sorry Brian, meant "can't" instead of "can"

That's OK. Go tip back a pint!

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On Monday, January 31, 2022 at 3:25:10 AM UTC-5, Johnny Billquist wrote:
> On 2022-01-31 01:22, Simon Clubley wrote:
> > On 2022-01-29, Scott Dorsey <klu...@panix.com> wrote:
> >>
> >> Pascal is pretty limited but makes it hard to shoot yourself in the foot.
> >> And most implementations don't use null-terminated strings which are the
> >> most serious source of vulnerabilities in C code.
> >> --scott
> >>
> >
> > I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
> The problem is that the ISO standard for Pascal is pretty useless. Which
> is why every useful Pascal have extensions...
> And they are all different...
> Which makes everything very non-standard...
>
> But Pascal is definitely not that bad a language. But it has it's warts...
>
> Johnny
There are two Pascal standards. ISO 7185 is the traditional Wirth language
with the addition of conformant arrays. Then there is ISO 10206 "Extended Pascal"
which was the follow-on. The committee (I was the secretary) didn't want to just
keep revising (changing) the base standard like you see today with C, C++, Fortran,
etc. Due to some politics, we went with a totally separate standard. Looking back, that
was a bad decision.

EP does attempt to standardize many of the concepts like a MODULE syntax, run-time
sized types, etc. While the syntax might be slightly different, you can see may of the
VMS Pascal features in the standard.

Of course, it isn't a real standard if nobody implements it. That's what happened in the
BASIC eco-system. I'd say VMS Pascal does about 50% of the actual features and syntax
of EP; 25% of the features but with our older syntax; 25% yet to be implement. Over all,
Extended Pascal is quite good at medium-to-large applications.

We also have an appendix/technical report on adding object-oriented features on top of
Extended Pascal. [To my knowledge, nobody ever implemented it.]

On Monday, January 31, 2022 at 3:33:06 AM UTC-5, Johnny Billquist wrote:
> On 2022-01-31 01:43, Arne Vajhøj wrote:
> > On 1/30/2022 7:19 PM, Simon Clubley wrote:
> >> On 2022-01-29, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >>> On 1/29/2022 1:53 AM, George Cornelius wrote:
> >>>>
> >>>> Works on Eisner.
> >>>>
> >>>> $ show sys/noproc
> >>>> OpenVMS V8.4-2L2 on node EISNER 29-JAN-2022 [...]
> >>>>
> >>>> Here's the memory layout synopsis from a linker map:
> >>>>
> >>>> Virtual memory allocated: 00010000 0005FFFF
> >>>> 00050000 (327680. bytes, 640. pages)
> >>>> 64-Bit Virtual memory allocated: 00000000 00000000
> >>>> 00000000
> >>>> 80000000
> >>>> 80010000 00010000 (65536. bytes, 128. pages)
> >>>>
> >>>> The example, though, shows too small an allocation to escape 32 bit
> >>>> address space.
> >>>
> >>> I consider 0000000080000000 to be 64 bit space.
> >>>
> >>> 0000000000000000 - 000000007FFFFFFF is P0 and P1 space
> >>> FFFFFFFF80000000 - FFFFFFFFFFFFFFFF is S0 and S1 space
> >>> 0000000080000000 and upward is P2 space
> >>>
> >>
> >> I think George's point is that this specific address can be
> >> represented in a 32-bit pointer.
> >
> > It can't.
> >
> > A 32 bit pointer with the value 80000000 will end up as
> > FFFFFFFF80000000.
> Since when are pointers considered to be signed and need sign extension?
>
> Johnny
The OpenVMS Calling Standard says that. As other have said, it helped with moving code
from VAX to Alpha and matched the memory layout. It allowed the OS to keep 32-bit pointers
in many system data structures and have them considered as system addresses..

As Andreas pointed out (no pun intended), if you can prevent that sign-extension, you can
get another bit of address space if you are willing to promise not to ever touch a system address.
Some languages like that build/use descriptors (like Pascal and BASIC) know about this
sign-extension internally. In C, you can typecast your way out of it since you access descriptors manually.

On 2022-01-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/30/2022 7:20 PM, Simon Clubley wrote:
>> On 2022-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> And it is not just me.
>>>
>>> The rust people are rewriting GNU Coreutils (C) in
>>> rust.
>>>
>>> https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022
>>>
>>
>> Let me know when the Rust compiler runs on all the architectures
>> that Linux runs on. :-)
>
> They are missing some.
>
> Rust supports x86, x86-64, ARM, MIPS, PPC, RISC-V and mainframe.
>
> So they are missing Alpha, PA, Itanium, SPARC and several
> lesser ones.
>
> But who actually runs Linux on one of those?
>

The point is that the Linux kernel is built around portability to
whatever architecture you want to run it on.

You can get a C compiler for everything someone could be interested
in running the Linux kernel on. However, until you can make the same
guarantee for Rust, then Rust will be restricted to the non-core
parts of the Linux kernel (ie: some device drivers) because otherwise
Rust suddenly becomes the reason why you can't run Linux on some
specialist architecture.

Simon.

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

On 1/31/2022 3:33 AM, Johnny Billquist wrote:
> On 2022-01-31 01:43, Arne Vajhøj wrote:
>> On 1/30/2022 7:19 PM, Simon Clubley wrote:
>>> On 2022-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 1/29/2022 1:53 AM, George Cornelius wrote:
>>>>>
>>>>> Works on Eisner.
>>>>>
>>>>> $ show sys/noproc
>>>>> OpenVMS V8.4-2L2  on node EISNER   29-JAN-2022 [...]
>>>>>
>>>>> Here's the memory layout synopsis from a linker map:
>>>>>
>>>>> Virtual memory allocated:                         00010000 0005FFFF
>>>>> 00050000 (327680. bytes, 640. pages)
>>>>> 64-Bit Virtual memory allocated:                  00000000 00000000
>>>>> 00000000
>>>>>                                                     80000000
>>>>> 80010000 00010000 (65536. bytes, 128. pages)
>>>>>
>>>>> The example, though, shows too small an allocation to escape 32 bit
>>>>> address space.
>>>>
>>>> I consider 0000000080000000 to be 64 bit space.
>>>>
>>>> 0000000000000000 - 000000007FFFFFFF is P0 and P1 space
>>>> FFFFFFFF80000000 - FFFFFFFFFFFFFFFF is S0 and S1 space
>>>> 0000000080000000 and upward is P2 space
>>>>
>>>
>>> I think George's point is that this specific address can be
>>> represented in a 32-bit pointer.
>>
>> It can't.
>>
>> A 32 bit pointer with the value 80000000 will end up as
>> FFFFFFFF80000000.
>
> Since when are pointers considered to be signed and need sign extension?

Since VMS Alpha 1.0 I believe.

Arne

On 1/31/2022 3:25 AM, Johnny Billquist wrote:
> On 2022-01-31 01:22, Simon Clubley wrote:
>> On 2022-01-29, Scott Dorsey <kludge@panix.com> wrote:
>>>
>>> Pascal is pretty limited but makes it hard to shoot yourself in the
>>> foot.
>>> And most implementations don't use null-terminated strings which are the
>>> most serious source of vulnerabilities in C code.
>>> --scott
>>>
>>
>> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>
> The problem is that the ISO standard for Pascal is pretty useless. Which
> is why every useful Pascal have extensions...
> And they are all different...
> Which makes everything very non-standard...
>
> But Pascal is definitely not that bad a language. But it has it's warts...

Pascal as in Wirth Pascal is a very good language for what it was
intended for: teaching structured programming. It is just that real
world programs need a bit more.

Arne

On 1/31/2022 7:46 AM, John Reagan wrote:
> On Monday, January 31, 2022 at 3:25:10 AM UTC-5, Johnny Billquist wrote:
>> On 2022-01-31 01:22, Simon Clubley wrote:
>>> On 2022-01-29, Scott Dorsey <klu...@panix.com> wrote:
>>>>
>>>> Pascal is pretty limited but makes it hard to shoot yourself in the foot.
>>>> And most implementations don't use null-terminated strings which are the
>>>> most serious source of vulnerabilities in C code.
>>>> --scott
>>>>
>>>
>>> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>> The problem is that the ISO standard for Pascal is pretty useless. Which
>> is why every useful Pascal have extensions...
>> And they are all different...
>> Which makes everything very non-standard...
>>
>> But Pascal is definitely not that bad a language. But it has it's warts...

> There are two Pascal standards. ISO 7185 is the traditional Wirth language
> with the addition of conformant arrays. Then there is ISO 10206 "Extended Pascal"
> which was the follow-on. The committee (I was the secretary) didn't want to just
> keep revising (changing) the base standard like you see today with C, C++, Fortran,
> etc. Due to some politics, we went with a totally separate standard. Looking back, that
> was a bad decision.
>
> EP does attempt to standardize many of the concepts like a MODULE syntax, run-time
> sized types, etc. While the syntax might be slightly different, you can see may of the
> VMS Pascal features in the standard.
>
> Of course, it isn't a real standard if nobody implements it. That's what happened in the
> BASIC eco-system. I'd say VMS Pascal does about 50% of the actual features and syntax
> of EP; 25% of the features but with our older syntax; 25% yet to be implement. Over all,
> Extended Pascal is quite good at medium-to-large applications.
>
> We also have an appendix/technical report on adding object-oriented features on top of
> Extended Pascal. [To my knowledge, nobody ever implemented it.]

Object Pascal sort of became industry standard in that regard.

Arne

On 2022-01-31, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley
><clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> Fortran and COBOL are not suitable for writing operating system userland
>> tools.
>
> Why not?
>

For the same reason that OS designers moved from Fortran to C as the
system implementation language when C became available. C is simply
a better language than Fortran for those kinds of tasks.

As for COBOL, I invite you to try implementing something like CDU or
especially TPU in it. :-)

Simon.

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

On 1/30/2022 10:04 PM, Bill Gunshannon wrote:
> On 1/30/22 19:49, Arne Vajhøj wrote:
>> On 1/30/2022 7:20 PM, Simon Clubley wrote:
>>> On 2022-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> And it is not just me.
>>>>
>>>> The rust people are rewriting GNU Coreutils (C) in
>>>> rust.
>>>>
>>>> https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022
>>>>
>>>>
>>>
>>> Let me know when the Rust compiler runs on all the architectures
>>> that Linux runs on. :-)
>>
>> They are missing some.
>>
>> Rust supports x86, x86-64, ARM, MIPS, PPC, RISC-V and mainframe.
>>
>> So they are missing Alpha, PA, Itanium, SPARC and several
>> lesser ones.
>>
>> But who actually runs Linux on one of those?
>>
>
> I still run it on a SPARC.  If I still had an Alpha I would
> probably be running it n that, too.

I would run Solaris on SPARC and I do run VMS on Alpha
and keep Linux on x86-64. Are there any benefits
from running Linux on a less common platform?

Arne

On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I would run Solaris on SPARC and I do run VMS on Alpha
> and keep Linux on x86-64. Are there any benefits
> from running Linux on a less common platform?
>

One of the reasons Linux has taken off is that you can run it on
pretty much every single thing that is physically capable of hosting
it in terms of CPU power and memory/other resources.

This includes large mainframes all the way down to tiny embedded boards
running on some custom hardware/architecture.

Simon.

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

On 1/31/2022 9:02 AM, Simon Clubley wrote:
> On 2022-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> I would run Solaris on SPARC and I do run VMS on Alpha
>> and keep Linux on x86-64. Are there any benefits
>> from running Linux on a less common platform?
>
> One of the reasons Linux has taken off is that you can run it on
> pretty much every single thing that is physically capable of hosting
> it in terms of CPU power and memory/other resources.

Is it?

To me it seems that the industry impact of Linux is very much
centered around x86-64 servers and ARM Android devices.

Look at what Redhat and other actually support. There is a
reason for that.

Raspberry Pi is fun but it is not a B$ thing.

Arne

On 1/31/2022 8:42 AM, Simon Clubley wrote:
> On 2022-01-31, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> Fortran and COBOL are not suitable for writing operating system userland
>>> tools.
>>
>> Why not?
>
> For the same reason that OS designers moved from Fortran to C as the
> system implementation language when C became available.

I am not aware of any OS done in Fortran.

And the world did not switch to C for OS development when C was
invented. That happened 10-20 years later.

> C is simply
> a better language than Fortran for those kinds of tasks.

C is a good language for OS kernel.

I don't see it as particular well suited for user land utilities.
C's low level features are not needed and just add risk.

Arne