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

Simon.

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

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

On Thursday, January 27, 2022 at 2:31:50 PM UTC-5, Simon Clubley wrote:
> On 2022-01-27, Arne Vajhøj <ar...@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++.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

I suppose that the language chosen would depend upon what the "tool" does. I see no reason why Fortran couldn't be used or Basic for that matter. What difference does it make what language is used? As long as the appropriate RTLs are available, use what ever language you want. I have written code in many languages and use the one that makes my life easier. Just recently, I coded a MACRO32 module, because it was faster to code that way than to do the same thing in Pascal. I have used Fortran in a similar situation. I look more at what I am trying to do and use the language that will be the easiest.

Dan

> [...] As far as I can see, it's only C or maybe C++.

Choosing one and sticking with it might help to reduce the annoyances
resulting when every program does its file I/O in an idiosyncratic
(language-specific?) way. I realize that almost anything can be done in
almost any language, but expecting anyone to write his own exotic
user-open routine for every file just to get consistent attributes seems
unrealistic.

For example, I'm not amazed that a (written-in-C-for-Unix-)web-server
log file comes out as:

Record format: Stream_LF, maximum 0 bytes, longest 1057 bytes
Record attributes: Carriage return carriage control

but, although I might guess how, it's not immediately clear to me _why_
an FTP server log file (sys$sysdevice:[tcpip$ftp]tcpip$ftp_run.log)
should be:

Record format: VFC, 2 byte header, maximum 0 bytes, longest 0 bytes
Record attributes: Print file carriage control

while the corresponding anonymous FTP log file
(sys$sysdevice:[tcpip$ftp]tcpip$ftp_anonymous.log) is:

Record format: Variable length, maximum 0 bytes, longest 198 bytes
Record attributes: Carriage return carriage control

Every time I open that anonymous FTP log file with an editor (EDIT
/TPU), I see annoying little "CR" and "LF" characters at the end of
every line.

If a language like Fortran leads a programmer to create common text
files with quirky attributes, then I'd suggest using a different one.

> [...] As long as the appropriate RTLs are available, use what ever
> language you want. [...]

Not, I claim, the best philosophy in this situation.

> [...] I look more at what I am trying to do and use the language that
> will be the easiest.

Easiest for you, or easiest for the poor slob who has to try to
integrate the resulting scrap-box filled with mismatched/incompatible
pieces? Writing a quick tool for your own use is one task, and writing
part of an OS for general use is a different task. Coherence and
consistency might have greater value in one situation than another.

I claim.

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

What *obvious* reasons?

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

I speak to machines with the voice of humanity.

On 1/27/22 17:21, VAXman-@SendSpamHere.ORG wrote:
> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> 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.
>
> What *obvious* reasons?
>

Well, the first one that would come to my mind would be the diminishing
number of people who have ever seen or worked with Macro-32 and Bliss.
Heck, how many people are left that have even heard of Bliss.

bill

On 1/27/2022 5:21 PM, VAXman-@SendSpamHere.ORG wrote:
> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> 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.
>
> What *obvious* reasons?

Not cost efficient.

There is a reason why assembler programming is becoming so rare
as it is.

Arne

On 1/27/2022 5:13 PM, Steven Schweda wrote:
>> [...] As far as I can see, it's only C or maybe C++.
>
> Choosing one and sticking with it might help to reduce the annoyances
> resulting when every program does its file I/O in an idiosyncratic
> (language-specific?) way. I realize that almost anything can be done in
> almost any language, but expecting anyone to write his own exotic
> user-open routine for every file just to get consistent attributes seems
> unrealistic.

I believe all VMS languages has options in open for specifying
the file attributes.

fopen(...,"rfm=var")

OPEN(...,CARRIAGECONTROL='LIST')

etc..

Which I do not consider exotic.

Arne

> Which I do not consider exotic.

Sure, fine, but look at the results from the current blend of (what
are, I assume) defaults. Whether or not better results are so "easy",
the existing situation (mess) is the existing situation (mess).

As I said, "unrealistic". That was an inference, not a postulate.

On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
> > Which I do not consider exotic.
> Sure, fine, but look at the results from the current blend of (what
> are, I assume) defaults. Whether or not better results are so "easy",
> the existing situation (mess) is the existing situation (mess).
>
> As I said, "unrealistic". That was an inference, not a postulate.

Aren't C/C++ the only VMS languages capable of using the full 64 bit address space?
Perhaps some others are (partially) capable but it doesn't look at all convenient.
Pascal has IADDRESS64 in addition to IADDRESS but why bother to call a _64 system service when you can't really do much else with it?

K

On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>> Which I do not consider exotic.
>> Sure, fine, but look at the results from the current blend of (what
>> are, I assume) defaults. Whether or not better results are so "easy",
>> the existing situation (mess) is the existing situation (mess).
>>
>> As I said, "unrealistic". That was an inference, not a postulate.
>
> Aren't C/C++ the only VMS languages capable of using the full 64 bit address space?
> Perhaps some others are (partially) capable but it doesn't look at all convenient.
> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call a _64 system service when you can't really do much else with it?

I believe Fortran supports usage of P2 space.

Arne

On 01/28/22 00:57, Arne Vajhøj wrote:
> On 1/27/2022 5:21 PM, VAXman-@SendSpamHere.ORG wrote:
>> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> 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.
>>
>> What *obvious* reasons?
>
> Not cost efficient.
>
> There is a reason why assembler programming is becoming so rare
> as it is.
>
> Arne
>
>

Difficulty in maintenance, or even finding programmers fluent enough
to get the best results. If C can be a minefield for the unwary, then
you really are on your own with assembler and need to know a lot more
about the underlying machine architecture, os implementation and
more. Asembler only makes sense now for the lowest level system
programming, where there is not enough machine state to support a
high level language...

Chris

On 28/01/2022 15:31, chris wrote:
> On 01/28/22 00:57, Arne Vajhøj wrote:
>> On 1/27/2022 5:21 PM, VAXman-@SendSpamHere.ORG wrote:
>>> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley
>>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>> 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.
>>>
>>> What *obvious* reasons?
>>
>> Not cost efficient.
>>
>> There is a reason why assembler programming is becoming so rare
>> as it is.
>>
>> Arne
>>
>>
>
> Difficulty in maintenance, or even finding programmers fluent enough
> to get the best results. If C can be a minefield for the unwary, then
> you really are on your own with assembler and need to know a lot more
> about the underlying machine architecture, os implementation and
> more. Asembler only makes sense now for the lowest level system
> programming, where there is not enough machine state to support a
> high level language...
>
> Chris
>

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

Chris

--
Chris

On Friday, January 28, 2022 at 4:06:32 AM UTC-5, cao...@pitbulluk.org wrote:
> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
> > > Which I do not consider exotic.
> > Sure, fine, but look at the results from the current blend of (what
> > are, I assume) defaults. Whether or not better results are so "easy",
> > the existing situation (mess) is the existing situation (mess).
> >
> > As I said, "unrealistic". That was an inference, not a postulate.
> Aren't C/C++ the only VMS languages capable of using the full 64 bit address space?
> Perhaps some others are (partially) capable but it doesn't look at all convenient.
> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call a _64 system service when you can't really do much else with it?
>
> K
Pascal should allow full use of 64-bit addresses. You can put the [QUAD] attribute on a pointer (or pointer type). It will be a 64-bit pointer. Calling NEW for it will call LIB$GET_VM_64 and give you 64-bit memory.

What Pascal doesn't do is know how to build 64-bit descriptors. It was on my list.

On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajhøj wrote:
> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
> > On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
> >>> Which I do not consider exotic.
> >> Sure, fine, but look at the results from the current blend of (what
> >> are, I assume) defaults. Whether or not better results are so "easy",
> >> the existing situation (mess) is the existing situation (mess).
> >>
> >> As I said, "unrealistic". That was an inference, not a postulate.
> >
> > Aren't C/C++ the only VMS languages capable of using the full 64 bit address space?
> > Perhaps some others are (partially) capable but it doesn't look at all convenient.
> > Pascal has IADDRESS64 in addition to IADDRESS but why bother to call a _64 system service when you can't really do much else with it?
> I believe Fortran supports usage of P2 space.
>
> Arne
Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64 (or however it is spelled)
attribute. You can have "top level" 64-bit pointers but you can't get 64-bit pointers as fields in a structure.

On 2022-01-27, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>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.
>
> What *obvious* reasons?
>

1) No type safety (even C has _some_ type safety but not as much as say
Pascal, Ada, or the Wirth languages in general),

2) ability to make more really silly mistakes that the compiler will not
catch because it doesn't have enough information to tell you,

3) vast amount of effort to do anything significant compared with the amount
of effort required even in C to do the same thing,

4) lack of people who understand the languages when changes are required.

BLISS, and especially Macro-32, belong in the past for any brand new
programs (as opposed to maintaining existing ones).

The absolute minimum standard for any new applications these days is C.
(And yes, that's a _minimum_ standard. :-))

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

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

On 1/28/2022 12:37 PM, John Reagan wrote:
> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajhøj wrote:
>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>> Which I do not consider exotic.
>>>> Sure, fine, but look at the results from the current blend of (what
>>>> are, I assume) defaults. Whether or not better results are so "easy",
>>>> the existing situation (mess) is the existing situation (mess).
>>>>
>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>
>>> Aren't C/C++ the only VMS languages capable of using the full 64 bit address space?
>>> Perhaps some others are (partially) capable but it doesn't look at all convenient.
>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call a _64 system service when you can't really do much else with it?
>> I believe Fortran supports usage of P2 space.
>>
> Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64 (or however it is spelled)
> attribute. You can have "top level" 64-bit pointers but you can't get 64-bit pointers as fields in a structure.

Real Fortran programmer does not use pointers.

:-)

Example with common:

$ type f64.for
program f64
implicit none
real*8 x(10),y(10)
common /cx/x
!DEC$ATTRIBUTES ADDRESS64::cy
common /cy/y
write(*,'(1x,z16.16)') %loc(x)
write(*,'(1x,z16.16)') %loc(y)
end
$ for f64
$ link f64
$ run f64
0000000000040000
0000000080000000

Arne

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

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!

--
Chris

On 1/28/22 14:46, Arne Vajhøj wrote:
> On 1/28/2022 12:37 PM, John Reagan wrote:
>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajhøj wrote:
>>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>> Which I do not consider exotic.
>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>> are, I assume) defaults. Whether or not better results are so "easy",
>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>
>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>
>>>> Aren't C/C++ the only VMS languages capable of using the full 64 bit
>>>> address space?
>>>> Perhaps some others are (partially) capable but it doesn't look at
>>>> all convenient.
>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call
>>>> a _64 system service when you can't really do much else with it?
>>> I believe Fortran supports usage of P2 space.
>>>
>> Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64
>> (or however it is spelled)
>> attribute.   You can have "top level" 64-bit pointers but you can't
>> get 64-bit pointers as fields in a structure.
>
> Real Fortran programmer does not use pointers.
>
> :-)
>
> Example with common:
>
> $ type f64.for
>       program f64
>       implicit none
>       real*8 x(10),y(10)
>       common /cx/x
>       !DEC$ATTRIBUTES ADDRESS64::cy
>       common /cy/y
>       write(*,'(1x,z16.16)') %loc(x)
>       write(*,'(1x,z16.16)') %loc(y)
>       end
> $ for f64
> $ link f64
> $ run f64
> 0000000000040000
> 0000000080000000
>

I ran that thru every FORTRAN compiler I had. Sorry, it's not
FORTRAN.

bill

On 1/28/2022 3:44 PM, Bill Gunshannon wrote:
> On 1/28/22 14:46, Arne Vajhøj wrote:
>> On 1/28/2022 12:37 PM, John Reagan wrote:
>>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajhøj wrote:
>>>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>>> Which I do not consider exotic.
>>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>>> are, I assume) defaults. Whether or not better results are so "easy",
>>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>>
>>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>>
>>>>> Aren't C/C++ the only VMS languages capable of using the full 64
>>>>> bit address space?
>>>>> Perhaps some others are (partially) capable but it doesn't look at
>>>>> all convenient.
>>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to
>>>>> call a _64 system service when you can't really do much else with it?
>>>> I believe Fortran supports usage of P2 space.
>>>>
>>> Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64
>>> (or however it is spelled)
>>> attribute.   You can have "top level" 64-bit pointers but you can't
>>> get 64-bit pointers as fields in a structure.
>>
>> Real Fortran programmer does not use pointers.
>>
>> :-)
>>
>> Example with common:
>>
>> $ type f64.for
>>        program f64
>>        implicit none
>>        real*8 x(10),y(10)
>>        common /cx/x
>>        !DEC$ATTRIBUTES ADDRESS64::cy
>>        common /cy/y
>>        write(*,'(1x,z16.16)') %loc(x)
>>        write(*,'(1x,z16.16)') %loc(y)
>>        end
>> $ for f64
>> $ link f64
>> $ run f64
>> 0000000000040000
>> 0000000080000000
>>
>
> I ran that thru every FORTRAN compiler I had.  Sorry, it's not
> FORTRAN.

It should work with Fortran on VMS Alpha and VMS I64.

Above test is on VMS Alpha.

Arne

On 1/28/22 15:30, Chris Townley 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.
>>
>
> 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!
>
>

That's funny... I did a lot of applications programming in Assembler
back in the day. PDP-11, Z80, M68K. Did systems stuff later on but
I started as an Applications Programmer/Systems Analyst and while I
did a lot of COBOL, Fortran and Pascal often Assembler was needed
because of the limited resources of the machines.

bill

On 1/28/22 16:38, Arne Vajhøj wrote:
> On 1/28/2022 3:44 PM, Bill Gunshannon wrote:
>> On 1/28/22 14:46, Arne Vajhøj wrote:
>>> On 1/28/2022 12:37 PM, John Reagan wrote:
>>>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajhøj wrote:
>>>>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>>>> Which I do not consider exotic.
>>>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>>>> are, I assume) defaults. Whether or not better results are so
>>>>>>> "easy",
>>>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>>>
>>>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>>>
>>>>>> Aren't C/C++ the only VMS languages capable of using the full 64
>>>>>> bit address space?
>>>>>> Perhaps some others are (partially) capable but it doesn't look at
>>>>>> all convenient.
>>>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to
>>>>>> call a _64 system service when you can't really do much else with it?
>>>>> I believe Fortran supports usage of P2 space.
>>>>>
>>>> Fortran lets you allocate COMMON in P2 and it has the CDEC$
>>>> POINTER64 (or however it is spelled)
>>>> attribute.   You can have "top level" 64-bit pointers but you can't
>>>> get 64-bit pointers as fields in a structure.
>>>
>>> Real Fortran programmer does not use pointers.
>>>
>>> :-)
>>>
>>> Example with common:
>>>
>>> $ type f64.for
>>>        program f64
>>>        implicit none
>>>        real*8 x(10),y(10)
>>>        common /cx/x
>>>        !DEC$ATTRIBUTES ADDRESS64::cy
>>>        common /cy/y
>>>        write(*,'(1x,z16.16)') %loc(x)
>>>        write(*,'(1x,z16.16)') %loc(y)
>>>        end
>>> $ for f64
>>> $ link f64
>>> $ run f64
>>> 0000000000040000
>>> 0000000080000000
>>>
>>
>> I ran that thru every FORTRAN compiler I had.  Sorry, it's not
>> FORTRAN.
>
> It should work with Fortran on VMS Alpha and VMS I64.
>
> Above test is on VMS Alpha.
>

And which Fortran standard includes "!DEC$ATTRIBUTES ADDRESS64::cy"?

bill

On 28/01/2022 23:36, Bill Gunshannon wrote:
> On 1/28/22 15:30, Chris Townley 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.
>>>
>>
>> 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!
>>
>>
>
> That's funny...  I did a lot of applications programming in Assembler
> back in the day.  PDP-11, Z80, M68K.  Did systems stuff later on but
> I started as an Applications Programmer/Systems Analyst and while I
> did a lot of COBOL, Fortran and Pascal often Assembler was needed
> because of the limited resources of the machines.
>
> bill
>
But I only joined the programming team in the late 90s, and had moved to
alpha. Performance was rarely an issue.

Where it was was nothing to do with using a high level language - for
example I found a purge program on a large file that took nearly 3
hours. It read the whole file sequentially, with a lock, to delete about
10% of the records. I changed it to read without a lock, only getting a
lock if we needed to delete. Dropped to 10 or 15 minutes. No assembly
coded needed

--
Chris

On 1/28/2022 6:38 PM, Bill Gunshannon wrote:
> On 1/28/22 16:38, Arne Vajhøj wrote:
>> On 1/28/2022 3:44 PM, Bill Gunshannon wrote:
>>> On 1/28/22 14:46, Arne Vajhøj wrote:
>>>> On 1/28/2022 12:37 PM, John Reagan wrote:
>>>>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajhøj wrote:
>>>>>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>>>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>>>>> Which I do not consider exotic.
>>>>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>>>>> are, I assume) defaults. Whether or not better results are so
>>>>>>>> "easy",
>>>>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>>>>
>>>>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>>>>
>>>>>>> Aren't C/C++ the only VMS languages capable of using the full 64
>>>>>>> bit address space?
>>>>>>> Perhaps some others are (partially) capable but it doesn't look
>>>>>>> at all convenient.
>>>>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to
>>>>>>> call a _64 system service when you can't really do much else with
>>>>>>> it?
>>>>>> I believe Fortran supports usage of P2 space.
>>>>>>
>>>>> Fortran lets you allocate COMMON in P2 and it has the CDEC$
>>>>> POINTER64 (or however it is spelled)
>>>>> attribute.   You can have "top level" 64-bit pointers but you can't
>>>>> get 64-bit pointers as fields in a structure.
>>>>
>>>> Real Fortran programmer does not use pointers.
>>>>
>>>> :-)
>>>>
>>>> Example with common:
>>>>
>>>> $ type f64.for
>>>>        program f64
>>>>        implicit none
>>>>        real*8 x(10),y(10)
>>>>        common /cx/x
>>>>        !DEC$ATTRIBUTES ADDRESS64::cy
>>>>        common /cy/y
>>>>        write(*,'(1x,z16.16)') %loc(x)
>>>>        write(*,'(1x,z16.16)') %loc(y)
>>>>        end
>>>> $ for f64
>>>> $ link f64
>>>> $ run f64
>>>> 0000000000040000
>>>> 0000000080000000
>>>>
>>>
>>> I ran that thru every FORTRAN compiler I had.  Sorry, it's not
>>> FORTRAN.
>>
>> It should work with Fortran on VMS Alpha and VMS I64.
>>
>> Above test is on VMS Alpha.
>
> And which Fortran standard includes "!DEC$ATTRIBUTES ADDRESS64::cy"?

Anything newer than 90 or none depending on perspective.

It is a comment in standard Fortran 90+.

But only VMS Fortran Alpha, I64 and I assume x86-64 does something
based on it.

On the other hand these are the only platforms moving a common block
from P0 space to P2 space are relevant.

So it is actually pretty cool - does what it should on the platforms
where it is needed and treated as harmless comment on other
platforms.

And it does compile with GFortran. Although with a warning
about %loc being a legacy extension. One can use loc instead
of %loc.

Arne