On 5/24/21 9:24 AM, John Wallace wrote:
> On 24/05/2021 13:28, Simon Clubley wrote:
>> On 2021-05-21, Rich Alderson <news@alderson.users.panix.com> wrote:
>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>> VAX. Which is where VMS started (and 32-bit processors are where Unix
>>>> and Linux started). It was a lot easier to get 32-bit Unix/Linux
>>>> working
>>>> on 64-bit architectures than it was VMS.
>>>
>>> NB:  For the purposes of this discussion, Unix started on a *16*-bit
>>> architecture.  (We'll ignore the fact that it actually started on an
>>> 18-bit
>>> word addressed architecture.)
>>>
>>
>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>> and as I pointed out in response this just shows how much more portable
>> things are when you are using an implemention language not tied to the
>> architecture.
>>
>> Simon.
>>
>
> Yeah sure, UNIX code was so portable that back in the 1980s anything
> much more complex than "Hello World" had little chance of being portable
> between (e.g.) BSD and System V even on the very same hardware.
>
> When the two main camps can't even agree on the basics of opening a file
> from C,
> as in fd = open(...),
> it's no wonder there was a customer/vendor need for a Single UNIX
> Specification.
>
> Fortunately times have moved on since then.

That had a lot more to do with deliberate proprietariness than
anything else. AT&T saw itself losing what little bit of the
market they had grabbed and decided making theirs different and
incompatible was good business. Eventually SYSV versions ended
out including BSD compatibility libraries because it was obvious
which way was better. I don't remember seeing any BSD product
coming with a SYSV compatibility library.

bill

On 2021-05-24, John Wallace <johnwallace4@yahoo.co.uk> wrote:
> On 24/05/2021 13:28, Simon Clubley wrote:
>>
>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>> and as I pointed out in response this just shows how much more portable
>> things are when you are using an implemention language not tied to the
>> architecture.
>>
>
> Yeah sure, UNIX code was so portable that back in the 1980s anything
> much more complex than "Hello World" had little chance of being portable
> between (e.g.) BSD and System V even on the very same hardware.
>
> When the two main camps can't even agree on the basics of opening a file
> from C,
> as in fd = open(...),
> it's no wonder there was a customer/vendor need for a Single UNIX
> Specification.
>
> Fortunately times have moved on since then.

You are confusing functionality of an operating system with the
portability of an operating system between architectures.

Your comments above talk about functionality within an operating
system. I am talking about the ease of porting an operating system
from one architecture to another.

The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.

Simon.

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

On 5/24/2021 2:05 PM, Simon Clubley wrote:
> On 2021-05-24, John Wallace <johnwallace4@yahoo.co.uk> wrote:
>> On 24/05/2021 13:28, Simon Clubley wrote:
>>>
>>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>>> and as I pointed out in response this just shows how much more portable
>>> things are when you are using an implemention language not tied to the
>>> architecture.
>>>
>>
>> Yeah sure, UNIX code was so portable that back in the 1980s anything
>> much more complex than "Hello World" had little chance of being portable
>> between (e.g.) BSD and System V even on the very same hardware.
>>
>> When the two main camps can't even agree on the basics of opening a file
>> from C,
>> as in fd = open(...),
>> it's no wonder there was a customer/vendor need for a Single UNIX
>> Specification.
>>
>> Fortunately times have moved on since then.
>
> You are confusing functionality of an operating system with the
> portability of an operating system between architectures.
>
> Your comments above talk about functionality within an operating
> system. I am talking about the ease of porting an operating system
> from one architecture to another.
>
> The choice of implementation language does not decide the functionality
> of an operating system. It is however a major factor in how easy or not
> it is to port that operating system to another architecture.

Even when (hawk, spit, gag) C doesn't work the same on different
architectures?

--
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

On 05/24/21 14:59, Bill Gunshannon wrote:
> On 5/24/21 9:24 AM, John Wallace wrote:
>> On 24/05/2021 13:28, Simon Clubley wrote:
>>> On 2021-05-21, Rich Alderson <news@alderson.users.panix.com> wrote:
>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>
>>>>> VAX. Which is where VMS started (and 32-bit processors are where Unix
>>>>> and Linux started). It was a lot easier to get 32-bit Unix/Linux
>>>>> working
>>>>> on 64-bit architectures than it was VMS.
>>>>
>>>> NB: For the purposes of this discussion, Unix started on a *16*-bit
>>>> architecture. (We'll ignore the fact that it actually started on an
>>>> 18-bit
>>>> word addressed architecture.)
>>>>
>>>
>>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>>> and as I pointed out in response this just shows how much more portable
>>> things are when you are using an implemention language not tied to the
>>> architecture.
>>>
>>> Simon.
>>>
>>
>> Yeah sure, UNIX code was so portable that back in the 1980s anything
>> much more complex than "Hello World" had little chance of being
>> portable between (e.g.) BSD and System V even on the very same hardware.
>>
>> When the two main camps can't even agree on the basics of opening a
>> file from C,
>> as in fd = open(...),
>> it's no wonder there was a customer/vendor need for a Single UNIX
>> Specification.
>>
>> Fortunately times have moved on since then.
>
> That had a lot more to do with deliberate proprietariness than
> anything else. AT&T saw itself losing what little bit of the
> market they had grabbed and decided making theirs different and
> incompatible was good business. Eventually SYSV versions ended
> out including BSD compatibility libraries because it was obvious
> which way was better. I don't remember seeing any BSD product
> coming with a SYSV compatibility library.
>
> bill
>

That's quite true, though Sun started off with a BSD flavour unix,
(SunOs) then incorporated the more useful bits of SysV when later
editions of Solaris were released. Streams being one such idea, but
there were others as well. Quite a bit of cross fertilisation...

Chris

On 05/25/21 00:58, Dave Froble wrote:
> On 5/24/2021 2:05 PM, Simon Clubley wrote:
>> On 2021-05-24, John Wallace <johnwallace4@yahoo.co.uk> wrote:
>>> On 24/05/2021 13:28, Simon Clubley wrote:
>>>>
>>>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>>>> and as I pointed out in response this just shows how much more portable
>>>> things are when you are using an implemention language not tied to the
>>>> architecture.
>>>>
>>>
>>> Yeah sure, UNIX code was so portable that back in the 1980s anything
>>> much more complex than "Hello World" had little chance of being portable
>>> between (e.g.) BSD and System V even on the very same hardware.
>>>
>>> When the two main camps can't even agree on the basics of opening a file
>>> from C,
>>> as in fd = open(...),
>>> it's no wonder there was a customer/vendor need for a Single UNIX
>>> Specification.
>>>
>>> Fortunately times have moved on since then.
>>
>> You are confusing functionality of an operating system with the
>> portability of an operating system between architectures.
>>
>> Your comments above talk about functionality within an operating
>> system. I am talking about the ease of porting an operating system
>> from one architecture to another.
>>
>> The choice of implementation language does not decide the functionality
>> of an operating system. It is however a major factor in how easy or not
>> it is to port that operating system to another architecture.
>
> Even when (hawk, spit, gag) C doesn't work the same on different
> architectures?
>

No problem if you write portable code and don't rely on invisible
underlying architecture or OS differences. Code I wrote decades ago
is still usable now...

Chris

On 5/24/2021 7:58 PM, Dave Froble wrote:
> On 5/24/2021 2:05 PM, Simon Clubley wrote:
>> On 2021-05-24, John Wallace <johnwallace4@yahoo.co.uk> wrote:
>>> On 24/05/2021 13:28, Simon Clubley wrote:
>>>>
>>>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>>>> and as I pointed out in response this just shows how much more portable
>>>> things are when you are using an implemention language not tied to the
>>>> architecture.
>>>>
>>>
>>> Yeah sure, UNIX code was so portable that back in the 1980s anything
>>> much more complex than "Hello World" had little chance of being portable
>>> between (e.g.) BSD and System V even on the very same hardware.
>>>
>>> When the two main camps can't even agree on the basics of opening a file
>>> from C,
>>> as in fd = open(...),
>>> it's no wonder there was a customer/vendor need for a Single UNIX
>>> Specification.
>>>
>>> Fortunately times have moved on since then.
>>
>> You are confusing functionality of an operating system with the
>> portability of an operating system between architectures.
>>
>> Your comments above talk about functionality within an operating
>> system. I am talking about the ease of porting an operating system
>> from one architecture to another.
>>
>> The choice of implementation language does not decide the functionality
>> of an operating system. It is however a major factor in how easy or not
>> it is to port that operating system to another architecture.
>
> Even when (hawk, spit, gag) C doesn't work the same on different
> architectures?

I think the answer depends on the question.

Can you just compile an OS written in C for a different
platform and it will run?

No. There may be differences in C implementation. And there
will also be some code that has to be platform specific.

Is it easier to port an OS written in to another platform
than to port an OS written in assembler to another
platform?

Yes. A lot of code will just work. And some careful
ifdef'ing can minimize the impact from the remaining
problems.

Arne

On 5/24/2021 8:01 PM, chris wrote:
> On 05/25/21 00:58, Dave Froble wrote:
>> On 5/24/2021 2:05 PM, Simon Clubley wrote:
>>> On 2021-05-24, John Wallace <johnwallace4@yahoo.co.uk> wrote:
>>>> On 24/05/2021 13:28, Simon Clubley wrote:
>>>>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>>>>> and as I pointed out in response this just shows how much more
>>>>> portable
>>>>> things are when you are using an implemention language not tied to the
>>>>> architecture.
>>>>>
>>>>
>>>> Yeah sure, UNIX code was so portable that back in the 1980s anything
>>>> much more complex than "Hello World" had little chance of being
>>>> portable
>>>> between (e.g.) BSD and System V even on the very same hardware.
>>>>
>>>> When the two main camps can't even agree on the basics of opening a
>>>> file
>>>> from C,
>>>> as in fd = open(...),
>>>> it's no wonder there was a customer/vendor need for a Single UNIX
>>>> Specification.
>>>>
>>>> Fortunately times have moved on since then.
>>>
>>> You are confusing functionality of an operating system with the
>>> portability of an operating system between architectures.
>>>
>>> Your comments above talk about functionality within an operating
>>> system. I am talking about the ease of porting an operating system
>>> from one architecture to another.
>>>
>>> The choice of implementation language does not decide the functionality
>>> of an operating system. It is however a major factor in how easy or not
>>> it is to port that operating system to another architecture.
>>
>> Even when (hawk, spit, gag) C doesn't work the same on different
>> architectures?
>
> No problem if you write portable code and don't rely on invisible
> underlying architecture or OS differences. Code I wrote decades ago
> is still usable now...

It is certainly possible to write portable C code.

But it is not trivial to write portable C code. Usage
of implementation specific behavior, assumptions
about various sizes etc..

Arne

On 5/24/21 7:58 PM, Dave Froble wrote:
> On 5/24/2021 2:05 PM, Simon Clubley wrote:
>> On 2021-05-24, John Wallace <johnwallace4@yahoo.co.uk> wrote:
>>> On 24/05/2021 13:28, Simon Clubley wrote:
>>>>
>>>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>>>> and as I pointed out in response this just shows how much more portable
>>>> things are when you are using an implemention language not tied to the
>>>> architecture.
>>>>
>>>
>>> Yeah sure, UNIX code was so portable that back in the 1980s anything
>>> much more complex than "Hello World" had little chance of being portable
>>> between (e.g.) BSD and System V even on the very same hardware.
>>>
>>> When the two main camps can't even agree on the basics of opening a file
>>> from C,
>>> as in fd = open(...),
>>> it's no wonder there was a customer/vendor need for a Single UNIX
>>> Specification.
>>>
>>> Fortunately times have moved on since then.
>>
>> You are confusing functionality of an operating system with the
>> portability of an operating system between architectures.
>>
>> Your comments above talk about functionality within an operating
>> system. I am talking about the ease of porting an operating system
>> from one architecture to another.
>>
>> The choice of implementation language does not decide the functionality
>> of an operating system. It is however a major factor in how easy or not
>> it is to port that operating system to another architecture.
>
> Even when (hawk, spit, gag) C doesn't work the same on different
> architectures?
>

Got any good examples? Are you sure it wasn't just a bad
implementation?

bill

On 5/24/21 7:59 PM, chris wrote:
> On 05/24/21 14:59, Bill Gunshannon wrote:
>> On 5/24/21 9:24 AM, John Wallace wrote:
>>> On 24/05/2021 13:28, Simon Clubley wrote:
>>>> On 2021-05-21, Rich Alderson <news@alderson.users.panix.com> wrote:
>>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>>
>>>>>> VAX. Which is where VMS started (and 32-bit processors are where Unix
>>>>>> and Linux started). It was a lot easier to get 32-bit Unix/Linux
>>>>>> working
>>>>>> on 64-bit architectures than it was VMS.
>>>>>
>>>>> NB:  For the purposes of this discussion, Unix started on a *16*-bit
>>>>> architecture.  (We'll ignore the fact that it actually started on an
>>>>> 18-bit
>>>>> word addressed architecture.)
>>>>>
>>>>
>>>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>>>> and as I pointed out in response this just shows how much more portable
>>>> things are when you are using an implemention language not tied to the
>>>> architecture.
>>>>
>>>> Simon.
>>>>
>>>
>>> Yeah sure, UNIX code was so portable that back in the 1980s anything
>>> much more complex than "Hello World" had little chance of being
>>> portable between (e.g.) BSD and System V even on the very same hardware.
>>>
>>> When the two main camps can't even agree on the basics of opening a
>>> file from C,
>>> as in fd = open(...),
>>> it's no wonder there was a customer/vendor need for a Single UNIX
>>> Specification.
>>>
>>> Fortunately times have moved on since then.
>>
>> That had a lot more to do with deliberate proprietariness than
>> anything else. AT&T saw itself losing what little bit of the
>> market they had grabbed and decided making theirs different and
>> incompatible was good business. Eventually SYSV versions ended
>> out including BSD compatibility libraries because it was obvious
>> which way was better. I don't remember seeing any BSD product
>> coming with a SYSV compatibility library.
>>
>> bill
>>
>
> That's quite true, though Sun started off with a BSD flavour unix,
> (SunOs) then incorporated the more useful bits of SysV when later
> editions of Solaris were released. Streams being one such idea, but
> there were others as well. Quite a bit of cross fertilisation...

I don't remember any SYSVisms in SunOS. Certainly not STREAMS.
And Solaris was Suns attempt to abandon BSD in favor of SYSV.
For those of us who had been with SUN since M68000 days this
was pretty disastrous. Early Solaris performed badly and as you
might expect existing SunOS code could not be compiled to run
on Solaris without heavy modification. Even with all of the
BSD compatibility stuff included. It resulted in the University
I was working at beginning its migration away from SUN. I
expect the same happened elsewhere as well.

bill

On 5/24/2021 9:14 PM, Bill Gunshannon wrote:
> On 5/24/21 7:59 PM, chris wrote:
>> On 05/24/21 14:59, Bill Gunshannon wrote:
>>> That had a lot more to do with deliberate proprietariness than
>>> anything else. AT&T saw itself losing what little bit of the
>>> market they had grabbed and decided making theirs different and
>>> incompatible was good business. Eventually SYSV versions ended
>>> out including BSD compatibility libraries because it was obvious
>>> which way was better. I don't remember seeing any BSD product
>>> coming with a SYSV compatibility library.
>>
>> That's quite true, though Sun started off with a BSD flavour unix,
>> (SunOs) then incorporated the more useful bits of SysV when later
>> editions of Solaris were released. Streams being one such idea, but
>> there were others as well. Quite a bit of cross fertilisation...
>
> I don't remember any SYSVisms in SunOS.  Certainly not STREAMS.
> And Solaris was Suns attempt to abandon BSD in favor of SYSV.
> For those of us who had been with SUN since M68000 days this
> was pretty disastrous. Early Solaris performed badly and as you
> might expect existing SunOS code could not be compiled to run
> on Solaris without heavy modification.  Even with all of the
> BSD compatibility stuff included.  It resulted in the University
> I was working at beginning its migration away from SUN.  I
> expect the same happened elsewhere as well.

SunOS 1.x - 4.x was BSD (wiki claims some SysV stuff from
3.0 specifically IPC).

SunOS 5.x was SysV.

SunOS 4.x = Solaris 1.x and SunOS 5.x = Solaris 2.x.

Arne

On 5/24/2021 9:06 PM, Bill Gunshannon wrote:
> On 5/24/21 7:58 PM, Dave Froble wrote:
>> On 5/24/2021 2:05 PM, Simon Clubley wrote:
>>> The choice of implementation language does not decide the functionality
>>> of an operating system. It is however a major factor in how easy or not
>>> it is to port that operating system to another architecture.
>>
>> Even when (hawk, spit, gag) C doesn't work the same on different
>> architectures?
>
> Got any good examples?  Are you sure it wasn't just a bad
> implementation?

C compiler bugs are getting relative rare today.

But the C standard leaves a lot to the implementation.

Character set, actual size of basic data types, ones vs
twos complement, FP format, data alignment, actual size of
size_t, a lot around volatile etc.etc..

This makes it possible to write a "hardware close"
C compiler on any platform.

But it also makes it a bit tricky to write a C
program with guaranteed behavior on all
standard compliant C compilers.

Arne

On 5/25/21 8:46 AM, Arne Vajhøj wrote:
> On 5/24/2021 9:06 PM, Bill Gunshannon wrote:
>> On 5/24/21 7:58 PM, Dave Froble wrote:
>>> On 5/24/2021 2:05 PM, Simon Clubley wrote:
>>>> The choice of implementation language does not decide the functionality
>>>> of an operating system. It is however a major factor in how easy or not
>>>> it is to port that operating system to another architecture.
>>>
>>> Even when (hawk, spit, gag) C doesn't work the same on different
>>> architectures?
>>
>> Got any good examples?  Are you sure it wasn't just a bad
>> implementation?
>
> C compiler bugs are getting relative rare today.
>
> But the C standard leaves a lot to the implementation.
>
> Character set, actual size of basic data types, ones vs
> twos complement, FP format, data alignment, actual size of
> size_t, a lot around volatile etc.etc..

Except6 for "volatile" all of this is architecturally or OS
dependent and not a part of the C language.

>
> This makes it possible to write a "hardware close"
> C compiler on any platform.

Probably a deliberate decision.

>
> But it also makes it a bit tricky to write a C
> program with guaranteed behavior on all
> standard compliant C compilers.

The parts that are C will behave the same under any non-broken
C compiler. But stuff that is not a part of the C language is
obviously going to be a crap shoot.

The same being true of pretty much every other language. Where
does Fortran define size_t? Where does Pascal define floating
point format? Where does Python define data alignment? COBOL
does let you select character set but it, too, is limited to
what is supported by the architecture or OS. Can't select
Fielddata on a PC using Ryan/McFarland COBOL. :-)

There was a company once that made a car that also functioned
as a boat. Can we now say that all other cars are deficient
because they don't float?

bill

On 5/25/2021 9:31 AM, Bill Gunshannon wrote:
> On 5/25/21 8:46 AM, Arne Vajhøj wrote:
>> On 5/24/2021 9:06 PM, Bill Gunshannon wrote:
>>> On 5/24/21 7:58 PM, Dave Froble wrote:
>>>> On 5/24/2021 2:05 PM, Simon Clubley wrote:
>>>>> The choice of implementation language does not decide the
>>>>> functionality
>>>>> of an operating system. It is however a major factor in how easy or
>>>>> not
>>>>> it is to port that operating system to another architecture.
>>>>
>>>> Even when (hawk, spit, gag) C doesn't work the same on different
>>>> architectures?
>>>
>>> Got any good examples?  Are you sure it wasn't just a bad
>>> implementation?
>>
>> C compiler bugs are getting relative rare today.
>>
>> But the C standard leaves a lot to the implementation.
>>
>> Character set, actual size of basic data types, ones vs
>> twos complement, FP format, data alignment, actual size of
>> size_t, a lot around volatile etc.etc..
>
> Except6 for "volatile" all of this is architecturally or OS
> dependent and not a part of the C language.

All these items are explicit listed as implementation
defined in the C standard.

And defined in other more high level
languages standard.

>> This makes it possible to write a "hardware close"
>> C compiler on any platform.
>
> Probably a deliberate decision.

Yes.

>> But it also makes it a bit tricky to write a C
>> program with guaranteed behavior on all
>> standard compliant C compilers.
>
> The parts that are C will behave the same under any non-broken
> C compiler.  But stuff that is not a part of the C language is
> obviously going to be a crap shoot.

Not true.

Implementation defined behavior is features that exist in
all implementations of the language but behave differently.

Let us take the example of int. Most C programs will have
a lot of variables of that type.

But the C standard only guarantees that it can keep values
from -32767 to +32767. Any C program that relies on an
int variable keeping a value outside of that range is not
guaranteed to produce same result everywhere.

Doing an >> on it? Better be sure that it is positive. The
result of right shifting a negative int is also implementation
defined.

> The same being true of pretty  much every other language.

No. It may be true of many languages more than 40 years old,
but it is not generally true of newer languages.

Most newer languages define integers that are 16/32/64 bit
two's complement, FP's that are 32/64 bit IEEE, sizes/lengths that
are fixed bit size, memory models that define volatile
behavior etc.. And in memory alignment is typical made
irrelevant because it has to be specified explicit as part
of marshalling and unmarshalling.

>   Where
> does Fortran define size_t?  Where does Pascal define floating
> point format?  Where does Python define data alignment?  COBOL
> does let you select character set but it, too, is limited to
> what is supported by the architecture or OS.  Can't select
> Fielddata on a PC using Ryan/McFarland COBOL.  :-)

Fortran 1957
Cobol 1959
Pascal 1970

Python does not define alignment for ctypes Structure. But we can blame
that on C.

Documentation states:

<quote>
By default, Structure and Union fields are aligned in the same way the C
compiler does it. It is possible to override this behavior by specifying
a _pack_ class attribute in the subclass definition. This must be set to
a positive integer and specifies the maximum alignment for the fields.
This is what #pragma pack(n) also does in MSVC.
</quote>

So if C got it then Python would get it.

> There was a company once that made a car that also functioned
> as a boat.  Can we now say that all other cars are deficient
> because they don't float?

No.

But one can say that both floating and non-floating are not
guaranteed characteristics of a car.

Arne

On 05/25/21 01:11, Arne Vajhøj wrote:
> On 5/24/2021 7:58 PM, Dave Froble wrote:
>> On 5/24/2021 2:05 PM, Simon Clubley wrote:
>>> On 2021-05-24, John Wallace <johnwallace4@yahoo.co.uk> wrote:
>>>> On 24/05/2021 13:28, Simon Clubley wrote:
>>>>>
>>>>> Yes, oops. :-) Somebody already reminded me about this a few days ago
>>>>> and as I pointed out in response this just shows how much more
>>>>> portable
>>>>> things are when you are using an implemention language not tied to the
>>>>> architecture.
>>>>>
>>>>
>>>> Yeah sure, UNIX code was so portable that back in the 1980s anything
>>>> much more complex than "Hello World" had little chance of being
>>>> portable
>>>> between (e.g.) BSD and System V even on the very same hardware.
>>>>
>>>> When the two main camps can't even agree on the basics of opening a
>>>> file
>>>> from C,
>>>> as in fd = open(...),
>>>> it's no wonder there was a customer/vendor need for a Single UNIX
>>>> Specification.
>>>>
>>>> Fortunately times have moved on since then.
>>>
>>> You are confusing functionality of an operating system with the
>>> portability of an operating system between architectures.
>>>
>>> Your comments above talk about functionality within an operating
>>> system. I am talking about the ease of porting an operating system
>>> from one architecture to another.
>>>
>>> The choice of implementation language does not decide the functionality
>>> of an operating system. It is however a major factor in how easy or not
>>> it is to port that operating system to another architecture.
>>
>> Even when (hawk, spit, gag) C doesn't work the same on different
>> architectures?
>
> I think the answer depends on the question.
>
> Can you just compile an OS written in C for a different
> platform and it will run?
>
> No. There may be differences in C implementation. And there
> will also be some code that has to be platform specific.

C has been standardised for decades, but the C library can
cause problems between os's because of the required header
files, which vary between, say, Linux and FreeBSD.

The real problem is where the OS interfaces with the hardware.
That is taken care of in modern OS's with a hardware
abstraction layer, but some assembler will always be required
at low level, to deal with differing architectures, memory
management etc.

>
> Is it easier to port an OS written in to another platform
> than to port an OS written in assembler to another
> platform?
>
> Yes. A lot of code will just work. And some careful
> ifdef'ing can minimize the impact from the remaining
> problems.
>
> Arne
>
>
>

On 2021-05-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/25/2021 9:31 AM, Bill Gunshannon wrote:
>> On 5/25/21 8:46 AM, Arne Vajhøj wrote:
>>> But it also makes it a bit tricky to write a C
>>> program with guaranteed behavior on all
>>> standard compliant C compilers.
>>
>> The parts that are C will behave the same under any non-broken
>> C compiler.  But stuff that is not a part of the C language is
>> obviously going to be a crap shoot.
>
> Not true.
>
> Implementation defined behavior is features that exist in
> all implementations of the language but behave differently.
>
> Let us take the example of int. Most C programs will have
> a lot of variables of that type.
>

Even when they should be using unsigned integers but that's no
different to any other languages that make signed integers the default.

> But the C standard only guarantees that it can keep values
> from -32767 to +32767. Any C program that relies on an
> int variable keeping a value outside of that range is not
> guaranteed to produce same result everywhere.
>

As you should well know Arne, that has been irrelevant for any new code
for at least a couple of decades due to the introduction of data types
whose size (and signed/unsigned attribute) _are_ guaranteed as part of
the standard.

I am of course talking about (for example) uint8_t, int16_t, uint32_t, etc.

If you need a guaranteed integer size in your code, use one of the
above or one of the various other similar data types instead of an int.

>
>> The same being true of pretty  much every other language.
>
> No. It may be true of many languages more than 40 years old,
> but it is not generally true of newer languages.
>
> Most newer languages define integers that are 16/32/64 bit
> two's complement, FP's that are 32/64 bit IEEE, sizes/lengths that
> are fixed bit size, memory models that define volatile
> behavior etc.. And in memory alignment is typical made
> irrelevant because it has to be specified explicit as part
> of marshalling and unmarshalling.
>

C also has rules about the scope of volatile statements and what
reordering of statements is and is not allowed by the standard
between volatile points.

Beyond that, you have to know your architecture for the small bits
of your code that need volatile attributes and that level of detail
does not depend on the programming language.

Simon.

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

On 5/25/2021 2:07 PM, Simon Clubley wrote:
> On 2021-05-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/25/2021 9:31 AM, Bill Gunshannon wrote:
>>> On 5/25/21 8:46 AM, Arne Vajhøj wrote:
>>>> But it also makes it a bit tricky to write a C
>>>> program with guaranteed behavior on all
>>>> standard compliant C compilers.
>>>
>>> The parts that are C will behave the same under any non-broken
>>> C compiler.  But stuff that is not a part of the C language is
>>> obviously going to be a crap shoot.
>>
>> Not true.
>>
>> Implementation defined behavior is features that exist in
>> all implementations of the language but behave differently.
>>
>> Let us take the example of int. Most C programs will have
>> a lot of variables of that type.
>
> Even when they should be using unsigned integers but that's no
> different to any other languages that make signed integers the default.

Sometimes signed is needed.

But there are certainly a lot that should be unsigned.

>> But the C standard only guarantees that it can keep values
>> from -32767 to +32767. Any C program that relies on an
>> int variable keeping a value outside of that range is not
>> guaranteed to produce same result everywhere.
>
> As you should well know Arne, that has been irrelevant for any new code
> for at least a couple of decades due to the introduction of data types
> whose size (and signed/unsigned attribute) _are_ guaranteed as part of
> the standard.
>
> I am of course talking about (for example) uint8_t, int16_t, uint32_t, etc.
>
> If you need a guaranteed integer size in your code, use one of the
> above or one of the various other similar data types instead of an int.

Then you know that your code will either work or not compile.

But there is no guarantee that it will work.

These types are optional in the standard.

int_leastn_t and uint_leastn_t are not optional but they are not
exactly widely used.

>>> The same being true of pretty  much every other language.
>>
>> No. It may be true of many languages more than 40 years old,
>> but it is not generally true of newer languages.
>>
>> Most newer languages define integers that are 16/32/64 bit
>> two's complement, FP's that are 32/64 bit IEEE, sizes/lengths that
>> are fixed bit size, memory models that define volatile
>> behavior etc.. And in memory alignment is typical made
>> irrelevant because it has to be specified explicit as part
>> of marshalling and unmarshalling.
>
> C also has rules about the scope of volatile statements and what
> reordering of statements is and is not allowed by the standard
> between volatile points.

C volatile guarantees that access is not optimized away and that
volatile accesses are not reordered.

Which may be fine when used for direct HW access, but it totally
insufficient for multi-threaded programming.

A bunch of atomic stuff has been added to C 11 to try and solve that.

> Beyond that, you have to know your architecture for the small bits
> of your code that need volatile attributes and that level of detail
> does not depend on the programming language.

For many languages the behavior of volatile is defined in the
languages memory model. The generated code and runtime has to
ensure compliant behavior.

Arne

On Tue, 25 May 2021 10:35:45 -0400, Arne Vajhøj wrote:

> Doing an >> on it? Better be sure that it is positive. The result of
> right shifting a negative int is also implementation defined.

Which is why one uses unsigned ints.

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

> C compiler bugs are getting relative rare today.

Hah! 95 gcc bugs reported in the last week.

https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=7d

De

On 5/25/2021 6:53 PM, Dennis Boone wrote:
> > C compiler bugs are getting relative rare today.
>
> Hah! 95 gcc bugs reported in the last week.
>
> https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=7d

Maybe it would be better to say that C compilers have plenty of bugs
today, but rarely impacts the ability to comply with the C standard.

The list above contains for C:
* problem with -Woverride-init
* problem with __builtin_cpu_init()
* problem with __attribute__((unused))
* problem with -Wformat-extra-args
* problem with -Wvla-parameter

Arne

Nice to get a mention in that. It was 40 years ago and the first bit of commercial s/w I wrote!

Nick
On Thursday, 13 May 2021 at 15:56:48 UTC+1, Arne Vajhøj wrote:

> https://en.wikipedia.org/wiki/RSTS/E
>
> <quote>
> RSTS (/ˈrɪstɪs/) is a multi-user time-sharing operating system,
> initially developed by Evans Griffiths & Hart of Boston, and acquired by
> Digital Equipment Corporation (DEC, now part of Hewlett Packard) for the
> PDP-11 series of 16-bit minicomputers. The first version of RSTS
> (RSTS-11, Version 1) was implemented in 1970 by DEC software engineers
> that developed the TSS-8 time-sharing operating system for the PDP-8.
>
> ...
>
> 1970s
>
> The kernel of RSTS was programmed in the assembly language MACRO-11,
> compiled and installed to a disk using the CILUS program, running on a
> DOS-11 operating system. RSTS booted into an extended version of the
> BASIC programming language which DEC called "BASIC-PLUS". All of the
> system software CUSPS for the operating system, including the programs
> for resource accounting, login, logout, and managing the system, were
> written in BASIC-PLUS. From 1970 to 1973, RSTS ran in only 56K bytes of
> magnetic core memory (64 kilobytes including the memory-mapped I/O
> space). This would allow a system to have up to 16 terminals with a
> maximum of 17 jobs. The maximum program size was 16K bytes. By the end
> of 1973 DEC estimated there were 150 licensed systems running RSTS.
>
> In 1973 memory management support was included in RSTS (now RSTS/E) for
> the newer DEC PDP-11/40 and PDP-11/45 minicomputers (the PDP-11/20 was
> only supported under RSTS-11). The introduction of memory management in
> the newer PDP-11 computers not only meant these machines were able to
> address four times the amount of memory (18-bit addressing, 256K bytes),
> it also paved the way for the developers to separate user mode processes
> from the core of the kernel.
>
> In 1975 memory management support was again updated for the newer 22-bit
> addressable PDP-11/70. RSTS systems could now be expanded to use as much
> as two megabytes of memory running up to 63 jobs. The RTS and CCL
> concepts were introduced although they had to be compiled in during
> "SYSGEN". Multi-terminal service was introduced which would allow a
> single job the ability to control multiple terminals (128 total).
> Large-message send/receive and interprocess communication became very
> sophisticated and efficient. By August there are 1,200 licensed systems.
>
> In 1977 the installation process for RSTS was no longer dependent on
> DOS-11. The RSTS kernel could now be compiled under the RT-11 RTS,
> formatted as a kernel file with RT-11 SILUS, and copied to the system or
> other disks, while the computer was time-sharing. The BASIC-PLUS RTS (as
> well as RT-11, RSX-11, TECO and third party RTSs) all ran as user mode
> processes, independent of the RSTS kernel. A systems manager could now
> decide during the bootstrap phase which RTS to run as the systems
> default KBM. By now, there were some 3,100 licensed systems.
>
> In 1978 the final memory management update was included for all machines
> that could support 22bit addressing. RSTS could now use the maximum
> amount of memory available to a PDP-11 (4 megabytes). Support was also
> included for SUPERVISORY mode which made RSTS the first DEC operating
> system with this capability. DECnet was also supported as well as remote
> diagnostics from field service technicians at the RDC in Colorado
> Springs, Colorado (a DEC subscription service). By the end of the
> decade, there are over 5,000 licensed systems.
>
> ...
>
> BASIC-PLUS
> Programs written in BASIC-PLUS ran under the BASIC RTS, which allowed
> them up to 32K bytes of memory (out of 64K total). The language was
> interpreted, each different keyword being internally converted to a
> unique byte code and the variables and data being indexed and stored
> separately within the memory space. The internal byte-code format was
> known as PCODE - when the interactive SAVE command was issued, the BASIC
> Plus RTS simply saved the working memory area to a disk file with a
> ".BAC" extension. Although this format was undocumented, two Electronic
> Engineering undergraduates from Southampton University in the UK (Nick
> de Smith and David Garrod) developed a decompiler that could reverse
> engineer BAC files into their original BASIC Plus source, complete with
> original line numbers and variable names (both subsequently worked for
> DEC). The rest of the memory was used by the BASIC RTS itself. If one
> wrote programs in a language that permitted true binary executables such
> as BASIC-Plus-2, FORTRAN-IV, or Macro Assembler, then the amount of
> memory available would be 56K (8K allocated to the RTS).
> </quote>
>
> https://en.wikipedia.org/wiki/BASIC-PLUS
>
> <quote>
> BASIC-PLUS is an extended dialect of the BASIC programming language that
> was developed by Digital Equipment Corporation (DEC) for use on its
> RSTS/E time-sharing operating system for the PDP-11 series of 16-bit
> minicomputers in the early 1970s through the 1980s.
>
> BASIC-PLUS was based on BASIC-8 for the TSS/8, itself based very closely
> on the original Dartmouth BASIC. BASIC-PLUS added a number of new
> structures, as well as features from JOSS concerning conditional
> statements and formatting. In turn, BASIC-PLUS was the version on which
> the original Microsoft BASIC was patterned.
>
> The language was later rewritten as a true compiler as BASIC-Plus-2, and
> was ported to the VAX-11 platform as that machine's native BASIC
> implementation. This version survived several platform changes, and is
> today known as VSI BASIC for OpenVMS.
>
> ...
>
> Syntax and features
>
> BASIC-PLUS is patterned closely on later versions of Dartmouth BASIC,
> including its powerful MAT commands. On top of this, DEC added a number
> of unique flow-control structures.
>
> Line numbers were positive integers from 1 to 32767.
> </quote>
>
> Again way before my time.
>
> Arne

On 15/03/2022 12:32, ni...@desmith.net wrote:
> Nice to get a mention in that. It was 40 years ago and the first bit of commercial s/w I wrote!
>
> Nick
> On Thursday, 13 May 2021 at 15:56:48 UTC+1, Arne Vajhøj wrote:
>
>> https://en.wikipedia.org/wiki/RSTS/E
>>
>> <quote>
>> RSTS (/ˈrɪstɪs/) is a multi-user time-sharing operating system,
>> initially developed by Evans Griffiths & Hart of Boston, and acquired by
>> Digital Equipment Corporation (DEC, now part of Hewlett Packard) for the
>> PDP-11 series of 16-bit minicomputers. The first version of RSTS
>> (RSTS-11, Version 1) was implemented in 1970 by DEC software engineers
>> that developed the TSS-8 time-sharing operating system for the PDP-8.
>>
>> ...
>>
>> 1970s
>>
>> The kernel of RSTS was programmed in the assembly language MACRO-11,
>> compiled and installed to a disk using the CILUS program, running on a
>> DOS-11 operating system. RSTS booted into an extended version of the
>> BASIC programming language which DEC called "BASIC-PLUS". All of the
>> system software CUSPS for the operating system, including the programs
>> for resource accounting, login, logout, and managing the system, were
>> written in BASIC-PLUS. From 1970 to 1973, RSTS ran in only 56K bytes of
>> magnetic core memory (64 kilobytes including the memory-mapped I/O
>> space). This would allow a system to have up to 16 terminals with a
>> maximum of 17 jobs. The maximum program size was 16K bytes. By the end
>> of 1973 DEC estimated there were 150 licensed systems running RSTS.
>>
>> In 1973 memory management support was included in RSTS (now RSTS/E) for
>> the newer DEC PDP-11/40 and PDP-11/45 minicomputers (the PDP-11/20 was
>> only supported under RSTS-11). The introduction of memory management in
>> the newer PDP-11 computers not only meant these machines were able to
>> address four times the amount of memory (18-bit addressing, 256K bytes),
>> it also paved the way for the developers to separate user mode processes
>> from the core of the kernel.
>>
>> In 1975 memory management support was again updated for the newer 22-bit
>> addressable PDP-11/70. RSTS systems could now be expanded to use as much
>> as two megabytes of memory running up to 63 jobs. The RTS and CCL
>> concepts were introduced although they had to be compiled in during
>> "SYSGEN". Multi-terminal service was introduced which would allow a
>> single job the ability to control multiple terminals (128 total).
>> Large-message send/receive and interprocess communication became very
>> sophisticated and efficient. By August there are 1,200 licensed systems.
>>
>> In 1977 the installation process for RSTS was no longer dependent on
>> DOS-11. The RSTS kernel could now be compiled under the RT-11 RTS,
>> formatted as a kernel file with RT-11 SILUS, and copied to the system or
>> other disks, while the computer was time-sharing. The BASIC-PLUS RTS (as
>> well as RT-11, RSX-11, TECO and third party RTSs) all ran as user mode
>> processes, independent of the RSTS kernel. A systems manager could now
>> decide during the bootstrap phase which RTS to run as the systems
>> default KBM. By now, there were some 3,100 licensed systems.
>>
>> In 1978 the final memory management update was included for all machines
>> that could support 22bit addressing. RSTS could now use the maximum
>> amount of memory available to a PDP-11 (4 megabytes). Support was also
>> included for SUPERVISORY mode which made RSTS the first DEC operating
>> system with this capability. DECnet was also supported as well as remote
>> diagnostics from field service technicians at the RDC in Colorado
>> Springs, Colorado (a DEC subscription service). By the end of the
>> decade, there are over 5,000 licensed systems.
>>
>> ...
>>
>> BASIC-PLUS
>> Programs written in BASIC-PLUS ran under the BASIC RTS, which allowed
>> them up to 32K bytes of memory (out of 64K total). The language was
>> interpreted, each different keyword being internally converted to a
>> unique byte code and the variables and data being indexed and stored
>> separately within the memory space. The internal byte-code format was
>> known as PCODE - when the interactive SAVE command was issued, the BASIC
>> Plus RTS simply saved the working memory area to a disk file with a
>> ".BAC" extension. Although this format was undocumented, two Electronic
>> Engineering undergraduates from Southampton University in the UK (Nick
>> de Smith and David Garrod) developed a decompiler that could reverse
>> engineer BAC files into their original BASIC Plus source, complete with
>> original line numbers and variable names (both subsequently worked for
>> DEC). The rest of the memory was used by the BASIC RTS itself. If one
>> wrote programs in a language that permitted true binary executables such
>> as BASIC-Plus-2, FORTRAN-IV, or Macro Assembler, then the amount of
>> memory available would be 56K (8K allocated to the RTS).
>> </quote>
>>
>> https://en.wikipedia.org/wiki/BASIC-PLUS
>>
>> <quote>
>> BASIC-PLUS is an extended dialect of the BASIC programming language that
>> was developed by Digital Equipment Corporation (DEC) for use on its
>> RSTS/E time-sharing operating system for the PDP-11 series of 16-bit
>> minicomputers in the early 1970s through the 1980s.
>>
>> BASIC-PLUS was based on BASIC-8 for the TSS/8, itself based very closely
>> on the original Dartmouth BASIC. BASIC-PLUS added a number of new
>> structures, as well as features from JOSS concerning conditional
>> statements and formatting. In turn, BASIC-PLUS was the version on which
>> the original Microsoft BASIC was patterned.
>>
>> The language was later rewritten as a true compiler as BASIC-Plus-2, and
>> was ported to the VAX-11 platform as that machine's native BASIC
>> implementation. This version survived several platform changes, and is
>> today known as VSI BASIC for OpenVMS.
>>
>> ...
>>
>> Syntax and features
>>
>> BASIC-PLUS is patterned closely on later versions of Dartmouth BASIC,
>> including its powerful MAT commands. On top of this, DEC added a number
>> of unique flow-control structures.
>>
>> Line numbers were positive integers from 1 to 32767.
>> </quote>
>>
>> Again way before my time.
>>
>> Arne

Story goes:

Programmer entered a BASIC program
1! PROGRAM NAME
32767 end

and could then report to his manager:
"Program is ready, just a few lines missing in the middle..."

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691