On 1/29/2022 8:56 PM, Bill Gunshannon wrote:
> On 1/29/22 20:46, Arne Vajhøj wrote:
>> On 1/29/2022 8:29 PM, Bill Gunshannon wrote:
>>> On 1/29/22 20:11, Arne Vajhøj wrote:
>>>>                      But even though Microsoft and Linux are
>>>> pretty far from each other in many aspects then they do share
>>>> an interest in looking at Rust as replacement for C.
>>>
>>> I will not be holding my breathe waiting for Unix to be re-written
>>> in Rust.
>>
>> Old commercial Unix'es will not be rewritten. Thee will be lucky
>> if they are even maintained.
>
> Real Unix is still alive and well and being maintained at least as good
> as Linux.

Tru64 is officially dead.

HP-UX last major release was 2007 and production of the HW (Itanium) has
stopped meaning that it is close to dead.

Solaris is hanging in a thread. Oracle has laid off a lot of engineering
and rumors continue to go around that it will be killed off.

AIX is the only one that seems in good shape support wise.

Arne

In article <st4sup$gh9$1@gioia.aioe.org>, Richard Maher <maher_rjSPAMLESS@hotmail.com> writes:
>On 28/01/2022 4:08 am, Arne Vajhøj wrote:
>> On 1/27/2022 2:31 PM, Simon Clubley wrote:
>>> On 2022-01-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 1/27/2022 11:25 AM, John Reagan wrote:
>>>>> On Thursday, January 27, 2022 at 3:39:38 AM UTC-5, Dave Froble wrote:
>>>>>> Why C, when there are better languages?
>>>>>
>>>>> If you are about to use the B-word, better is relative.
>>>>
>>>> Obviously.
>>>>
>>>> But not everybody is in love with C.
>>>>
>>>> Personally I consider C a fine language for OS kernel development
>>>> but not so great a language for more regular applications. And
>>>> DIR is really an application.
>>>>
>>>> I am not good at VMS Basic, so I would prefer VMS Pascal.
>>>>
>>>> :-)
>>>
>>> Pascal is acceptable, but Ada would be better. :-)
>>>
>>> On a more serious note, what would be an acceptable programming language
>>> for userland tools which need to be shipped as part of the operating
>>> system ?
>>>
>>> Let's look at the language options for creating a new userland level
>>> tool on VMS today:
>>>
>>> Macro-32 and BLISS are absolutely unsuitable for obvious reasons.
>>>
>>> Basic appears to be a poor choice when compared to the alternatives
>>> available.
>>>
>>> Ada is no longer available on VMS going forward.
>>>
>>> C is suitable, but is low-level.
>>>
>>> C++ is a possibility (provided a sane subset of the language is used).
>>> However, am I the only one who finds that C++ compilers across all
>>> operating systems get slower and slower as new versions some out ?
>>> Look at how long it takes to compile the LLVM toolkit for example. :-(
>>> :-(
>>>
>>> Pascal is also very much a possibility.
>>>
>>> Fortran and COBOL are not suitable for writing operating system userland
>>> tools.
>>>
>>> So what programming language would you use for a new userland tool on VMS
>>> if you couldn't use Pascal ? As far as I can see, it's only C or maybe
>>> C++.
>>
>> I believe Basic would be a lot better than C.
>>
>> Arne
>>
>
>And COBOL is the besterest.
>
>And if you can program some MACRO then you need a Garbage Collect to
>cover up yor lack of skill in managing memory.

I've never needed "garbage collection" and I've written some very large and complex
products all in Macro!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 1/30/22 08:36, VAXman-@SendSpamHere.ORG wrote:
> In article <st4sup$gh9$1@gioia.aioe.org>, Richard Maher <maher_rjSPAMLESS@hotmail.com> writes:
>> On 28/01/2022 4:08 am, Arne Vajhøj wrote:
>>> On 1/27/2022 2:31 PM, Simon Clubley wrote:
>>>> On 2022-01-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 1/27/2022 11:25 AM, John Reagan wrote:
>>>>>> On Thursday, January 27, 2022 at 3:39:38 AM UTC-5, Dave Froble wrote:
>>>>>>> Why C, when there are better languages?
>>>>>>
>>>>>> If you are about to use the B-word, better is relative.
>>>>>
>>>>> Obviously.
>>>>>
>>>>> But not everybody is in love with C.
>>>>>
>>>>> Personally I consider C a fine language for OS kernel development
>>>>> but not so great a language for more regular applications. And
>>>>> DIR is really an application.
>>>>>
>>>>> I am not good at VMS Basic, so I would prefer VMS Pascal.
>>>>>
>>>>> :-)
>>>>
>>>> Pascal is acceptable, but Ada would be better. :-)
>>>>
>>>> On a more serious note, what would be an acceptable programming language
>>>> for userland tools which need to be shipped as part of the operating
>>>> system ?
>>>>
>>>> Let's look at the language options for creating a new userland level
>>>> tool on VMS today:
>>>>
>>>> Macro-32 and BLISS are absolutely unsuitable for obvious reasons.
>>>>
>>>> Basic appears to be a poor choice when compared to the alternatives
>>>> available.
>>>>
>>>> Ada is no longer available on VMS going forward.
>>>>
>>>> C is suitable, but is low-level.
>>>>
>>>> C++ is a possibility (provided a sane subset of the language is used).
>>>> However, am I the only one who finds that C++ compilers across all
>>>> operating systems get slower and slower as new versions some out ?
>>>> Look at how long it takes to compile the LLVM toolkit for example. :-(
>>>> :-(
>>>>
>>>> Pascal is also very much a possibility.
>>>>
>>>> Fortran and COBOL are not suitable for writing operating system userland
>>>> tools.
>>>>
>>>> So what programming language would you use for a new userland tool on VMS
>>>> if you couldn't use Pascal ? As far as I can see, it's only C or maybe
>>>> C++.
>>>
>>> I believe Basic would be a lot better than C.
>>>
>>> Arne
>>>
>>
>> And COBOL is the besterest.
>>
>> And if you can program some MACRO then you need a Garbage Collect to
>> cover up yor lack of skill in managing memory.
>
> I've never needed "garbage collection" and I've written some very large and complex
> products all in Macro!

I have to admit I really didn't get this one either. I have worked
with a lot of assemblers and written a number of programs in them
and have never had a problem with garbage collection. Memory leaks
seem to be much more of a problem with higher level languages and
especially the newer language du jour.

bill

On 1/29/22 21:58, Arne Vajhøj wrote:
> On 1/29/2022 8:56 PM, Bill Gunshannon wrote:
>> On 1/29/22 20:46, Arne Vajhøj wrote:
>>> On 1/29/2022 8:29 PM, Bill Gunshannon wrote:
>>>> On 1/29/22 20:11, Arne Vajhøj wrote:
>>>>>                      But even though Microsoft and Linux are
>>>>> pretty far from each other in many aspects then they do share
>>>>> an interest in looking at Rust as replacement for C.
>>>>
>>>> I will not be holding my breathe waiting for Unix to be re-written
>>>> in Rust.
>>>
>>> Old commercial Unix'es will not be rewritten. Thee will be lucky
>>> if they are even maintained.
>>
>> Real Unix is still alive and well and being maintained at least as
>> good as Linux.
>
> Tru64 is officially dead.
>
> HP-UX last major release was 2007 and production of the HW (Itanium) has
> stopped meaning that it is close to dead.
>
> Solaris is hanging in a thread. Oracle has laid off a lot of engineering
> and rumors continue to go around that it will be killed off.
>
> AIX is the only one that seems in good shape support wise.
>

I said real, not proprietary.

FreeBSD, NetBSD, OpenBSD. pretty much anything that didn't drink
the SYSV KoolAid.

bill

On 1/30/2022 10:34 AM, Bill Gunshannon wrote:
> On 1/30/22 08:36, VAXman-@SendSpamHere.ORG wrote:
>> In article <st4sup$gh9$1@gioia.aioe.org>, Richard Maher
>> <maher_rjSPAMLESS@hotmail.com> writes:
>>> On 28/01/2022 4:08 am, Arne Vajhøj wrote:
>>>> On 1/27/2022 2:31 PM, Simon Clubley wrote:
>>>>> So what programming language would you use for a new userland tool
>>>>> on VMS
>>>>> if you couldn't use Pascal ? As far as I can see, it's only C or maybe
>>>>> C++.
>>>>
>>>> I believe Basic would be a lot better than C.
>>>
>>> And COBOL is the besterest.
>>>
>>> And if you can program some MACRO then you need a Garbage Collect to
>>> cover up yor lack of skill in managing memory.
>>
>> I've never needed "garbage collection" and I've written some very
>> large and complex
>> products all in Macro!
>
> I have to admit I really didn't get this one either.  I have worked
> with a lot of assemblers and written a number of programs in them
> and have never had a problem with garbage collection.  Memory leaks
> seem to be much more of a problem with higher level languages

That seems very plausible.

Assembler programmers are probably at average significant better
than the average of all programmers.

More care has to be put into the assembler code for other reasons
which spill over to memory management.

Even though large assembler code bases exist then I believe
that the real large ones comparable to the X MLOC or XX MLOC
that exist in Cobol, C, C++, Java etc..

> and
> especially the newer language du jour.

What languages?

Most languages from the last 30 years use GC.

Python use GC (reference count based).

Java, Kotlin, Scala and Groovy use GC (reachable based).

JavaScript use GC (reachable based).

C# and VB.NET use GC (reachable based).

PHP use GC (reference count based).

Swift use GC (reference count based).

Go use GC (reachable based).

Only Rust does not use GC, but its very unusual ownership
concept solve the same problem.

Arne

Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 1/29/22 19:26, Scott Dorsey 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.
>
>Isn't it time to drop this red herring. C was not the only and
>probably not the first to use null terminated strings. If anyone
>really cared it could have been fixed ages ago (it actually was
>in Safe C and we see how much acceptance that got!!)

It is in no way a red herring.

It's true that C was not the only and not the first language to use
null terminated strings.

And it's true that if anyone really cared it could have been fixed
ages ago.

But the fact that people don't care is alarming. Because the bugs
just keep coming and coming.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <memo.20220130154429.12544b@jgd.cix.co.uk>, jgd@cix.co.uk (John Dallman) writes:
>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.

BS. If/when memory is allocated it needs to be deallocated when it is no
longer needed. Same goes for pushing things on the stack -- push data on
and pop data off. Assembly language programmers are generally just better
at those sorts of things because the results of mucking up are not pretty.

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

I speak to machines with the voice of humanity.

On 1/30/2022 1:26 PM, VAXman-@SendSpamHere.ORG wrote:
> In article <memo.20220130154429.12544b@jgd.cix.co.uk>, jgd@cix.co.uk (John Dallman) writes:
>> 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.
>
> BS. If/when memory is allocated it needs to be deallocated when it is no
> longer needed. Same goes for pushing things on the stack -- push data on
> and pop data off. Assembly language programmers are generally just better
> at those sorts of things because the results of mucking up are not pretty.

....
push
....
pop
....

is manageable.

So is:

....
allocate
....
deallocate
....
return

The problem arise with the more complex flows where the allocating
routine pass the pointer on to something and return expecting some
other code to deallocate.

Arne

On 2022-01-30 19:40, Arne Vajhøj wrote:
> On 1/30/2022 1:26 PM, VAXman-@SendSpamHere.ORG wrote:
>> In article <memo.20220130154429.12544b@jgd.cix.co.uk>, jgd@cix.co.uk
>> (John Dallman) writes:
>>> 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.
>>
>> BS.  If/when memory is allocated it needs to be deallocated when it is no
>> longer needed.  Same goes for pushing things on the stack -- push data on
>> and pop data off.  Assembly language programmers are generally just
>> better
>> at those sorts of things because the results of mucking up are not
>> pretty.
>
> ...
> push
> ...
> pop
> ...
>
> is manageable.
>
> So is:
>
> ...
> allocate
> ...
> deallocate
> ...
> return
>
> The problem arise with the more complex flows where the allocating
> routine pass the pointer on to something and return expecting some
> other code to deallocate.

That is usually because of languages with very poor data ownership
models, which usually is a side effect of object oriented languages.

Complex flow itself isn't really creating any problems. It's all about
knowing who owns the data. But when you don't even know what code might
execute, known what data even exists, or who owns it, becomes a murky
pool. GC to the rescue (if you like calling that a rescue).

Johnny

In article <61f6dbb2$0$692$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>On 1/30/2022 1:26 PM, VAXman-@SendSpamHere.ORG wrote:
>> In article <memo.20220130154429.12544b@jgd.cix.co.uk>, jgd@cix.co.uk (John Dallman) writes:
>>> 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.
>>
>> BS. If/when memory is allocated it needs to be deallocated when it is no
>> longer needed. Same goes for pushing things on the stack -- push data on
>> and pop data off. Assembly language programmers are generally just better
>> at those sorts of things because the results of mucking up are not pretty.
>
>....
>push
>....
>pop
>....
>
>is manageable.
>
>So is:
>
>....
>allocate
>....
>deallocate
>....
>return
>
>The problem arise with the more complex flows where the allocating
>routine pass the pointer on to something and return expecting some
>other code to deallocate.

That's just poor coding or poor design if there's a memory leak.

FWIW, that sort of thing is done in the VMS kernel (eg. drivers) all of
the time.

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

I speak to machines with the voice of humanity.

On 2022-01-28, Chris Townley <news@cct-net.co.uk> wrote:
> On 28/01/2022 19:22, Simon Clubley wrote:
>> On 2022-01-28, Chris Townley <news@cct-net.co.uk> wrote:
>>>
>>> I agree wholeheartedly. When I joined our programming team, I stated
>>> that I would not learn Macro. When porting to Itanium, 3 modules of
>>> Macro didn't work, so I rewrote them: 1 in Basic, 2 in C. All was good!
>>>
>>> Luckily they were well documented...
>>>
>>
>> I actually do know _lots_ of assembly languages. My opinions are based
>> on knowledge, not ignorance.
>>
>> A sample of assembly languages I have either used in the past or are using
>> these days for specialist things: Macro-11, Macro-32, Alpha, x86, ARM,
>> MIPS, and the odd 8/16 bit little MCUs.
>>
>> Everything I use assembly language for these days is for specialist
>> reasons (ie: bare metal startup, bare metal interrupt handlers, getting
>> access to specialist hardware registers from a program, etc) and I switch
>> to at least C as soon as possible.
>>
>
> Simon, I was not deriding anybody who does write this level of code - I
> did a small amount of Z80 assembler in the 80s, but do not want to go
> back there. I am an application programmer, so for me there should be no
> need for assembly programming!
>

Actually, if you look again, you will see I was agreeing with you
and the above wasn't in response to you. :-)

Sometimes people say you are only criticising something because you
don't really understand it. I headed that off by pointing out my
experience with them and hence my opinions come from knowledge but
I should really have added it to the end of the previous reply... :-)

Simon.

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

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 ? :-)

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 5:25 PM, VAXman-@SendSpamHere.ORG wrote:
> In article <61f6dbb2$0$692$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>> On 1/30/2022 1:26 PM, VAXman-@SendSpamHere.ORG wrote:
>>> BS. If/when memory is allocated it needs to be deallocated when it is no
>>> longer needed. Same goes for pushing things on the stack -- push data on
>>> and pop data off. Assembly language programmers are generally just better
>>> at those sorts of things because the results of mucking up are not pretty.
>>
>> ....
>> push
>> ....
>> pop
>> ....
>>
>> is manageable.
>>
>> So is:
>>
>> ....
>> allocate
>> ....
>> deallocate
>> ....
>> return
>>
>> The problem arise with the more complex flows where the allocating
>> routine pass the pointer on to something and return expecting some
>> other code to deallocate.
>
> That's just poor coding or poor design if there's a memory leak.

A memory leak is a bug and somebody made a mistake if a bug
is introduced.

But that doesn't really change anything.

It is an observable fact that mistakes are made and bugs introduced
all the time and memory leaks are a common type of bug with languages
that require manual deallocation.

In the real world there are just two choices:
- say that developers should avoid errors and watch errors
continue to be made
- design programming languages, tools and processes
so that the provider fewer opportunities for errors

Arne

On 1/30/2022 3:49 PM, Johnny Billquist wrote:
> On 2022-01-30 19:40, Arne Vajhøj wrote:
>> On 1/30/2022 1:26 PM, VAXman-@SendSpamHere.ORG wrote:
>>> BS.  If/when memory is allocated it needs to be deallocated when it
>>> is no
>>> longer needed.  Same goes for pushing things on the stack -- push
>>> data on
>>> and pop data off.  Assembly language programmers are generally just
>>> better
>>> at those sorts of things because the results of mucking up are not
>>> pretty.
>>
>> ...
>> push
>> ...
>> pop
>> ...
>>
>> is manageable.
>>
>> So is:
>>
>> ...
>> allocate
>> ...
>> deallocate
>> ...
>> return
>>
>> The problem arise with the more complex flows where the allocating
>> routine pass the pointer on to something and return expecting some
>> other code to deallocate.
>
> That is usually because of languages with very poor data ownership
> models, which usually is a side effect of object oriented languages.
>
> Complex flow itself isn't really creating any problems. It's all about
> knowing who owns the data. But when you don't even know what code might
> execute, known what data even exists, or who owns it, becomes a murky
> pool. GC to the rescue (if you like calling that a rescue).

If we consider uncertainty about who owns data to be complexity then ...

Arne

On 2022-01-29, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/29/2022 8:23 AM, Bill Gunshannon wrote:
>>
>> Just because a non-Fortran compiler accepts it doesn't make it Fortran.
>>
>
> "non-Fortran compiler" ???????????????????
> -
> Oh, no, Simon has been cloned. We are doomed!
>
>:-)
>

:-)

Unlike Bill, Simon recognises a pragma statement when he sees one. :-)

Simon.

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

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.

Simon.

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

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. :-)

Simon.

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

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.

--
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 7:22 PM, 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.
>

Everything is limited in some way.

Whether those ways are important is the real issue.

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

Arne

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?

Arne

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> 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.
>
>I wouldn't call Pascal "limited". DEC used it to implement VAXELN...

DEC Pascal... is a lot more than just Pascal.
But even so, Modula-2 is probably a better choice for implementing a kernel.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/30/2022 9:21 PM, Scott Dorsey wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> 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.
>>
>> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>
> DEC Pascal... is a lot more than just Pascal.
> But even so, Modula-2 is probably a better choice for implementing a kernel.

It is important to distinguish between Pascal as in ISO Pascal
versus VMS Pascal.

I really like Modula-2. And I believe that PIM/ISO Modula-2 is a
lot more useful than ISO Pascal for real development. But VMS Pascal
is a lot more capable than ISO Pascal.

VMS Pascal has a module system and it has system specific
integer types.

VMS Pascal does not have FOR "C" but VMS calling convention can
do the same.

So what is the key differentiator here? Coroutines? ASM keyword?

Arne

On 1/30/2022 9:34 PM, Arne Vajhøj wrote:
> On 1/30/2022 9:21 PM, Scott Dorsey wrote:
>> Simon Clubley  <clubley@remove_me.eisner.decus.org-Earth.UFP> 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.
>>>
>>> I wouldn't call Pascal "limited". DEC used it to implement VAXELN...
>>
>> DEC Pascal... is a lot more than just Pascal.
>> But even so, Modula-2 is probably a better choice for implementing a
>> kernel.
>
> It is important to distinguish between Pascal as in ISO Pascal
> versus VMS Pascal.
>
> I really like Modula-2. And I believe that PIM/ISO Modula-2 is a
> lot more useful than ISO Pascal for real development. But VMS Pascal
> is a lot more capable than ISO Pascal.
>
> VMS Pascal has a module system and it has system specific
> integer types.
>
> VMS Pascal does not have FOR "C" but VMS calling convention can
> do the same.
>
> So what is the key differentiator here? Coroutines? ASM keyword?

Or is it the modules?

Modula-2 modules are better than VMS Pascal modules.

Modula-2 modules are practically OO encapsulation capability.

Arne

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