On 7/18/2023 8:47 PM, Arne Vajhøj wrote:
> On 7/18/2023 8:34 PM, Dave Froble wrote:
>> On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
>>> I am pretty sure that if VMS kernel had most Macro-32 and
>>> Bliss code rewritten to C, then VMS kernel would be
>>> smaller than just systemd. :-)
>>
>> I have to wonder why you think re-writing in C would be "smaller" (whatever
>> that is) than what's there today?
>
> Same functionality implemented in different languages
> result in a different number of lines of code.

So, you're talking about source files?

Do you also claim that the executable code would also be smaller?

> Usually measured in LoC/FP.
>
> C is fewer lines than Macro-32.
>
> I am not sure that Bliss to C will really reduce LoC that much - it
> was just bundled in with Macro-32.
>
> VMS Basic is fewer lines than C. :-)
>
> Usually it is rather irrelevant, but when comparing complexity
> of two code bases written in different languages it can be
> relevant.
>
> Arne
>
>
>

--
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 7/18/2023 9:25 PM, Dave Froble wrote:
> On 7/18/2023 8:47 PM, Arne Vajhøj wrote:
>> On 7/18/2023 8:34 PM, Dave Froble wrote:
>>> On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
>>>> I am pretty sure that if VMS kernel had most Macro-32 and
>>>> Bliss code rewritten to C, then VMS kernel would be
>>>> smaller than just systemd. :-)
>>>
>>> I have to wonder why you think re-writing in C would be "smaller"
>>> (whatever
>>> that is) than what's there today?
>>
>> Same functionality implemented in different languages
>> result in a different number of lines of code.
>
> So, you're talking about source files?

Yes.

> Do you also claim that the executable code would also be smaller?

No.

Arne

On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
> On 7/18/2023 9:25 PM, Dave Froble wrote:
>> On 7/18/2023 8:47 PM, Arne Vajhøj wrote:
>>> On 7/18/2023 8:34 PM, Dave Froble wrote:
>>>> On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
>>>>> I am pretty sure that if VMS kernel had most Macro-32 and
>>>>> Bliss code rewritten to C, then VMS kernel would be
>>>>> smaller than just systemd. :-)
>>>>
>>>> I have to wonder why you think re-writing in C would be "smaller" (whatever
>>>> that is) than what's there today?
>>>
>>> Same functionality implemented in different languages
>>> result in a different number of lines of code.
>>
>> So, you're talking about source files?
>
> Yes.
>
>> Do you also claim that the executable code would also be smaller?
>
> No.
>
> Arne
>
>

Then, what would be the benefit?

For example:

Stat% = SYS$QIOW( , ! Event flag &
Ch% By Value, ! VMS channel &
IO$_ACPCONTROL By Value,! Operation &
IOSB::Stat%, ! I/O status block &
, ! AST routine &
, ! AST parameter &
Temp% By Desc, ! P1 sub-func code &
URL$, ! P2 URL string &
RetLen%, ! P3-return len &
IP$, ! P4-output string &
, ! P5 &
) ! P6

The above is rather easy to understand, from some perspectives. Would it be
"smaller" if strung out on one line? Sure. Would it be a bit harder to
understand? Most definitely. Prone to mistakes also.

Compilers, assemblers, and such ignore the "white space", so it really doesn't
matter to the executable. However, the white space and comments can make code
easier to understand, and avoid mistakes.

So, what's the issue with larger source files?

--
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 2023-07-19, Dave Froble <davef@tsoft-inc.com> wrote:
> On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
>> On 7/18/2023 9:25 PM, Dave Froble wrote:
>>> On 7/18/2023 8:47 PM, Arne Vajhøj wrote:
>>>> On 7/18/2023 8:34 PM, Dave Froble wrote:
>>>>> On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
>>>>>> I am pretty sure that if VMS kernel had most Macro-32 and
>>>>>> Bliss code rewritten to C, then VMS kernel would be
>>>>>> smaller than just systemd. :-)

David, please read this again. Arne is talking about the VMS kernel
being smaller than it currently is. I have no way to compare it to
systemd however. :-)

>>>>>
>>>>> I have to wonder why you think re-writing in C would be "smaller" (whatever
>>>>> that is) than what's there today?
>>>>
>>>> Same functionality implemented in different languages
>>>> result in a different number of lines of code.
>>>
>>> So, you're talking about source files?
>>
>> Yes.
>>
>>> Do you also claim that the executable code would also be smaller?
>>
>> No.
>>
>
> Then, what would be the benefit?
>

For one thing, if you didn't have to worry about the Macro-32 and
Bliss crap, the VMS port would have been completed years ago.

It's also a hell of a lot easier, quicker, and more robust, to
write something in C than it is in Macro-32 or Bliss.

There are also many languages in turn that have the same advantage
over C, but that doesn't change the above.

> For example:
>
> Stat% = SYS$QIOW( , ! Event flag &
> Ch% By Value, ! VMS channel &
> IO$_ACPCONTROL By Value,! Operation &
> IOSB::Stat%, ! I/O status block &
> , ! AST routine &
> , ! AST parameter &
> Temp% By Desc, ! P1 sub-func code &
> URL$, ! P2 URL string &
> RetLen%, ! P3-return len &
> IP$, ! P4-output string &
> , ! P5 &
> ) ! P6
>
> The above is rather easy to understand, from some perspectives. Would it be
> "smaller" if strung out on one line? Sure. Would it be a bit harder to
> understand? Most definitely. Prone to mistakes also.
>

Hmmm David, at what point above did Arne talk about replacing Basic code
with C code ? He's talking about replacing lower-level language code
with higher-level C code.

> Compilers, assemblers, and such ignore the "white space", so it really doesn't
> matter to the executable. However, the white space and comments can make code
> easier to understand, and avoid mistakes.
>
> So, what's the issue with larger source files?
>

It's not the larger source files. It's the very painful architecture
specific coding and lower levels of abstraction that Macro-32 and Bliss
bring to the table.

Simon.

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

On 7/19/2023 1:32 PM, Simon Clubley wrote:
> On 2023-07-19, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
>>> On 7/18/2023 9:25 PM, Dave Froble wrote:
>>>> On 7/18/2023 8:47 PM, Arne Vajhøj wrote:
>>>>> On 7/18/2023 8:34 PM, Dave Froble wrote:
>>>>>> On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
>>>>>>> I am pretty sure that if VMS kernel had most Macro-32 and
>>>>>>> Bliss code rewritten to C, then VMS kernel would be
>>>>>>> smaller than just systemd. :-)
>
> David, please read this again. Arne is talking about the VMS kernel
> being smaller than it currently is. I have no way to compare it to
> systemd however. :-)
>
>>>>>>
>>>>>> I have to wonder why you think re-writing in C would be "smaller" (whatever
>>>>>> that is) than what's there today?
>>>>>
>>>>> Same functionality implemented in different languages
>>>>> result in a different number of lines of code.
>>>>
>>>> So, you're talking about source files?
>>>
>>> Yes.
>>>
>>>> Do you also claim that the executable code would also be smaller?
>>>
>>> No.
>>>
>>
>> Then, what would be the benefit?
>>
>
> For one thing, if you didn't have to worry about the Macro-32 and
> Bliss crap, the VMS port would have been completed years ago.
>
> It's also a hell of a lot easier, quicker, and more robust, to
> write something in C than it is in Macro-32 or Bliss.
>
> There are also many languages in turn that have the same advantage
> over C, but that doesn't change the above.
>
>> For example:
>>
>> Stat% = SYS$QIOW( , ! Event flag &
>> Ch% By Value, ! VMS channel &
>> IO$_ACPCONTROL By Value,! Operation &
>> IOSB::Stat%, ! I/O status block &
>> , ! AST routine &
>> , ! AST parameter &
>> Temp% By Desc, ! P1 sub-func code &
>> URL$, ! P2 URL string &
>> RetLen%, ! P3-return len &
>> IP$, ! P4-output string &
>> , ! P5 &
>> ) ! P6
>>
>> The above is rather easy to understand, from some perspectives. Would it be
>> "smaller" if strung out on one line? Sure. Would it be a bit harder to
>> understand? Most definitely. Prone to mistakes also.
>>
>
> Hmmm David, at what point above did Arne talk about replacing Basic code
> with C code ? He's talking about replacing lower-level language code
> with higher-level C code.
>
>> Compilers, assemblers, and such ignore the "white space", so it really doesn't
>> matter to the executable. However, the white space and comments can make code
>> easier to understand, and avoid mistakes.
>>
>> So, what's the issue with larger source files?
>>
>
> It's not the larger source files. It's the very painful architecture
> specific coding and lower levels of abstraction that Macro-32 and Bliss
> bring to the table.
>
> Simon.
>

Simon, do you need some "reading lessons"?

From above:

>>>> So, you're talking about source files?
>>>
>>> Yes.
>>>
>>>> Do you also claim that the executable code would also be smaller?
>>>
>>> No.

So, Arne is talking about the size of the source code. And that is what I
responded to. My example was showing the benefits of readability vs lines of
source code. Regardless of language.

--
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 7/19/2023 12:03 PM, Dave Froble wrote:
> On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
>> On 7/18/2023 9:25 PM, Dave Froble wrote:
>>> On 7/18/2023 8:47 PM, Arne Vajhøj wrote:
>>>> On 7/18/2023 8:34 PM, Dave Froble wrote:
>>>>> On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
>>>>>> I am pretty sure that if VMS kernel had most Macro-32 and
>>>>>> Bliss code rewritten to C, then VMS kernel would be
>>>>>> smaller than just systemd. :-)
>>>>>
>>>>> I have to wonder why you think re-writing in C would be "smaller"
>>>>> (whatever
>>>>> that is) than what's there today?
>>>>
>>>> Same functionality implemented in different languages
>>>> result in a different number of lines of code.
>>>
>>> So, you're talking about source files?
>>
>> Yes.
>>
>>> Do you also claim that the executable code would also be smaller?
>>
>> No.
>
> Then, what would be the benefit?

I am not talking about benefits.

I am talking about how to compare complexity (functionality)
of software written in different languages.

X1 lines of C can be more complex than X2 lines of Macro-32
even though X1 < X2. Because if the Macro-32 was
rewritten to X3 lines of C then it could happen that X3 < X1.

> For example:
>
>         Stat% = SYS$QIOW(       ,                       !  Event flag &
>                                 Ch% By Value,           !  VMS channel &
>                                 IO$_ACPCONTROL By Value,!  Operation &
>                                 IOSB::Stat%,            !  I/O status
> block &
>                                 ,                       !  AST routine &
>                                 ,                       !  AST parameter &
>                                 Temp% By Desc,          !  P1 sub-func
> code &
>                                 URL$,                   !  P2 URL string &
>                                 RetLen%,                !  P3-return len &
>                                 IP$,                    !  P4-output
> string &
>                                 ,                       !  P5 &
>                                 )                       !  P6
>
> The above is rather easy to understand, from some perspectives.  Would
> it be "smaller" if strung out on one line?  Sure.  Would it be a bit
> harder to understand?  Most definitely.  Prone to mistakes also.
>
> Compilers, assemblers, and such ignore the "white space", so it really
> doesn't matter to the executable.  However, the white space and comments
> can make code easier to understand, and avoid mistakes.

The issue is well known.

Ideally the measurement should be SLOC which is counting "statements",
which is independent of formatting.

But it is easier to count plain LOC.

And the assumption is that when looking at millions of lines
of code by thousands of different developers, then SLOC is
proportional to LOC.

> So, what's the issue with larger source files?

The point was comparison of functionality.

Re the simple vs complex point.

Arne

On 7/19/2023 1:32 PM, Simon Clubley wrote:
> On 2023-07-19, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
>>> On 7/18/2023 9:25 PM, Dave Froble wrote:
>>>> Do you also claim that the executable code would also be smaller?
>>>
>>> No.
>>
>> Then, what would be the benefit?
>
> For one thing, if you didn't have to worry about the Macro-32 and
> Bliss crap, the VMS port would have been completed years ago.

Are you sure?

It is not my impression that the various VMS ISA migrations has
caused rewrite of lots of Macro-32 and Bliss.

My impression is that:
- they create the Macro-32 and Bliss compilers for the new platform
- they compile the old Macro-32 and Bliss code dating back from the
70's and 80's
- the new code get written in C (plus a little bit of native
assembler where needed)

> It's also a hell of a lot easier, quicker, and more robust, to
> write something in C than it is in Macro-32 or Bliss.

I think they do write the new stuff in C.

Obviously if they have a need to read and understand some
code then reading C will be something like a factor 10
faster than reading Macro-32.

> It's not the larger source files. It's the very painful architecture
> specific coding and lower levels of abstraction that Macro-32 and Bliss
> bring to the table.

They are not architecture specific as as the same code
run on many platforms.

But Bliss is low level and Macro-32 is very low level. The same
Macro-32 code does not become high level just because it goes through
a compiler instead of an assembler.

Arne

On Wednesday, July 19, 2023 at 1:32:25 PM UTC-4, Simon Clubley wrote:
> On 2023-07-19, Dave Froble <da...@tsoft-inc.com> wrote:
> > On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
> >> On 7/18/2023 9:25 PM, Dave Froble wrote:
> >>> On 7/18/2023 8:47 PM, Arne Vajhøj wrote:
> >>>> On 7/18/2023 8:34 PM, Dave Froble wrote:
> >>>>> On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
> >>>>>> I am pretty sure that if VMS kernel had most Macro-32 and
> >>>>>> Bliss code rewritten to C, then VMS kernel would be
> >>>>>> smaller than just systemd. :-)
> David, please read this again. Arne is talking about the VMS kernel
> being smaller than it currently is. I have no way to compare it to
> systemd however. :-)
> >>>>>
> >>>>> I have to wonder why you think re-writing in C would be "smaller" (whatever
> >>>>> that is) than what's there today?
> >>>>
> >>>> Same functionality implemented in different languages
> >>>> result in a different number of lines of code.
> >>>
> >>> So, you're talking about source files?
> >>
> >> Yes.
> >>
> >>> Do you also claim that the executable code would also be smaller?
> >>
> >> No.
> >>
> >
> > Then, what would be the benefit?
> >
> For one thing, if you didn't have to worry about the Macro-32 and
> Bliss crap, the VMS port would have been completed years ago.
>
> It's also a hell of a lot easier, quicker, and more robust, to
> write something in C than it is in Macro-32 or Bliss.
>
You can keep saying that but won't make it true. Yes, we had to make 3 cross-compilers
to do the port. Even if the whole OS was written in DEC C with all the extensions in the code
base, we would have still had to make some sort of GEM-to-LLVM converter to get the DECC
compiler hooked to LLVM. (And Macro-32 doesn't even use that GEM-to-LLVM converter).
It would have save person years of work as we were working on XMACRO in parallel with
the G2L code for BLISS and C.

As for "easier, quick, robust", that's a matter of skill. The real benefits
of C over BLISS/MACRO include "floating point" and provided I/O package.

On 2023-07-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 7/19/2023 1:32 PM, Simon Clubley wrote:
>> On 2023-07-19, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
>>>> On 7/18/2023 9:25 PM, Dave Froble wrote:
>>>>> Do you also claim that the executable code would also be smaller?
>>>>
>>>> No.
>>>
>>> Then, what would be the benefit?
>>
>> For one thing, if you didn't have to worry about the Macro-32 and
>> Bliss crap, the VMS port would have been completed years ago.
>
> Are you sure?
>
> It is not my impression that the various VMS ISA migrations has
> caused rewrite of lots of Macro-32 and Bliss.
>
> My impression is that:
> - they create the Macro-32 and Bliss compilers for the new platform
> - they compile the old Macro-32 and Bliss code dating back from the
> 70's and 80's
> - the new code get written in C (plus a little bit of native
> assembler where needed)
>

You have missed what I am saying above, so I may have been too subtle.
Let me reword it: If VMS didn't have any Macro-32 or Bliss code in it,
and didn't need to support them as application level programming languages,
VMS would look much more internally like any another OS written in C does,
and the port would have been completed years ago.

As of this month, the VMS port has been going on for 9 years and it is
still not finished.

It doesn't take 9 years to port Linux to a brand-new architecture, even
if you first have to implement the compilers for that brand-new architecture.

Simon.

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

On 2023-07-19, John Reagan <xyzzy1959@gmail.com> wrote:
> On Wednesday, July 19, 2023 at 1:32:25?PM UTC-4, Simon Clubley wrote:
>> On 2023-07-19, Dave Froble <da...@tsoft-inc.com> wrote:
>> > On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
>> >> On 7/18/2023 9:25 PM, Dave Froble wrote:
>> >>> On 7/18/2023 8:47 PM, Arne Vajhøj wrote:
>> >>>> On 7/18/2023 8:34 PM, Dave Froble wrote:
>> >>>>> On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
>> >>>>>> I am pretty sure that if VMS kernel had most Macro-32 and
>> >>>>>> Bliss code rewritten to C, then VMS kernel would be
>> >>>>>> smaller than just systemd. :-)
>> David, please read this again. Arne is talking about the VMS kernel
>> being smaller than it currently is. I have no way to compare it to
>> systemd however. :-)
>> >>>>>
>> >>>>> I have to wonder why you think re-writing in C would be "smaller" (whatever
>> >>>>> that is) than what's there today?
>> >>>>
>> >>>> Same functionality implemented in different languages
>> >>>> result in a different number of lines of code.
>> >>>
>> >>> So, you're talking about source files?
>> >>
>> >> Yes.
>> >>
>> >>> Do you also claim that the executable code would also be smaller?
>> >>
>> >> No.
>> >>
>> >
>> > Then, what would be the benefit?
>> >
>> For one thing, if you didn't have to worry about the Macro-32 and
>> Bliss crap, the VMS port would have been completed years ago.
>>
>> It's also a hell of a lot easier, quicker, and more robust, to
>> write something in C than it is in Macro-32 or Bliss.
>>
> You can keep saying that but won't make it true. Yes, we had to make 3 cross-compilers
> to do the port. Even if the whole OS was written in DEC C with all the extensions in the code
> base, we would have still had to make some sort of GEM-to-LLVM converter to get the DECC
> compiler hooked to LLVM. (And Macro-32 doesn't even use that GEM-to-LLVM converter).
> It would have save person years of work as we were working on XMACRO in parallel with
> the G2L code for BLISS and C.
>

I keep looking at why the port is currently at 9 years and counting
compared to how long it takes to port Linux to a brand-new architecture
and keep wondering why it is taking so long.

There are some things you have had to implement, such as KESU emulation,
that Linux doesn't have to deal with, but I have a hard time seeing why
that would take more than a few months to design and implement.

I get the impression that you have had to spend a lot of effort to
duplicate low-level behaviour in a way that simply isn't a concern
with other operating systems due to the need, especially, to support
Macro-32 and ensure that code written at this low-level, and which
uses the various idioms as a result, continues to work.

> As for "easier, quick, robust", that's a matter of skill. The real benefits
> of C over BLISS/MACRO include "floating point" and provided I/O package.

No, the real benefits of C include the ability to use abstractions in
your code which make the code a lot quicker to write, where you can
focus much more on what you want, instead of having to lay out in
minute detail how to do it, and as a result your code also becomes
much more reusable and portable.

You can design complex data structures much more easily and get much
more help from the compiler in finding errors in your code.

For one really simple example, in C, you ask for a pointer and let the
compiler implement the pointer behind the scenes. Ie: you write:

char *ptr;

instead of:

uint32_t ptr;

In C, your normal application code works the same, regardless of whether
that pointer is 32-bits or 64-bits. If the lowest-level language in VMS
was C, this is what the RMS interface would conceptually look like:

struct {whatever}_rms_rab_t *rab;

instead of the current setup. Likewise for itemlists and other structures.

Things which are currently highly visible to the source code become
abstracted implementation details that normal source code simply doesn't
care about or have to deal with.

Simon.

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

On 7/20/2023 8:20 AM, Simon Clubley wrote:
> On 2023-07-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/19/2023 1:32 PM, Simon Clubley wrote:
>>> On 2023-07-19, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
>>>>> On 7/18/2023 9:25 PM, Dave Froble wrote:
>>>>>> Do you also claim that the executable code would also be smaller?
>>>>>
>>>>> No.
>>>>
>>>> Then, what would be the benefit?
>>>
>>> For one thing, if you didn't have to worry about the Macro-32 and
>>> Bliss crap, the VMS port would have been completed years ago.
>>
>> Are you sure?
>>
>> It is not my impression that the various VMS ISA migrations has
>> caused rewrite of lots of Macro-32 and Bliss.
>>
>> My impression is that:
>> - they create the Macro-32 and Bliss compilers for the new platform
>> - they compile the old Macro-32 and Bliss code dating back from the
>> 70's and 80's
>> - the new code get written in C (plus a little bit of native
>> assembler where needed)
>>
>
> You have missed what I am saying above, so I may have been too subtle.
> Let me reword it: If VMS didn't have any Macro-32 or Bliss code in it,
> and didn't need to support them as application level programming languages,
> VMS would look much more internally like any another OS written in C does,
> and the port would have been completed years ago.

It is obvious to the casual observer that some assembly language "tricks" would
make an assembly language compiler a bit (or more) tricky. Supporting Macro-32,
a basically 32 bit language (these days), is a significant task. Yeah, yeah, I
know, Macro-32 can do 64 bit stuff. However, it is not just for VMS, but also
for all those applications written in Macro-32 that are still in use. Now, I'm
rather sure Simon feels they should be re-implimented in another language. I
have to wonder whether the users of those apps feel the same way. I doubt it.
Nice of Simon to assign significant work to others.

Similar observations for Bliss.

> As of this month, the VMS port has been going on for 9 years and it is
> still not finished.

Better than abandoned ...

> It doesn't take 9 years to port Linux to a brand-new architecture, even
> if you first have to implement the compilers for that brand-new architecture.

Not the same thing at all.

For those with Linux apps, there are already platforms that can be used. The
same cannot be said for VMS. So VMS has additional needs, as in needed, and
just might be more work. Linux however, just isn't needed on additional platforms.

I can also imagine a "brand-new architecture" where a port of Linux just might
not be so easy.

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

In article <u9bag8$2n8ej$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>[snip]
>> As for "easier, quick, robust", that's a matter of skill. The real benefits
>> of C over BLISS/MACRO include "floating point" and provided I/O package.
>
>No, the real benefits of C include the ability to use abstractions in
>your code which make the code a lot quicker to write, where you can
>focus much more on what you want, instead of having to lay out in
>minute detail how to do it, and as a result your code also becomes
>much more reusable and portable.
>
>You can design complex data structures much more easily and get much
>more help from the compiler in finding errors in your code.
>
>For one really simple example, in C, you ask for a pointer and let the
>compiler implement the pointer behind the scenes. Ie: you write:
>
> char *ptr;
>
>instead of:
>
> uint32_t ptr;
>
>In C, your normal application code works the same, regardless of whether
>that pointer is 32-bits or 64-bits.

I don't know that I agree with this.

C is not a low-level language (seriously; it hasn't been for a
while: https://queue.acm.org/detail.cfm?id=3212479), but neither
is it a particularly high-level language.

And while, yes, there is a notion of pointer types as first
class objects built into the language, C programmers also pull a
lot of tricks like punning integers for pointers, and so forth
that make this fraught.

There are a few typedefs in e.g. <stdint.h> that can help out
here (`uintptr_t` and friends) but the language allows implicit,
lossy conversions and C code is often not as portable as one
would like to believe.

Moreover, in the past few decades, C _compilers_ have become
inhospitable to systems programmers, so much so that it is now
de facto impossible to write an OS kernel in well-defined C
code; that is, in C that doesn't invoke undefined behavior.
This, in turn, leads to needing lots of compiler-specific help
to force specific behaviors for these instances of UB
(https://arxiv.org/pdf/2201.07845.pdf).

>If the lowest-level language in VMS
>was C, this is what the RMS interface would conceptually look like:
>
> struct {whatever}_rms_rab_t *rab;
>
>instead of the current setup. Likewise for itemlists and other structures.
>
>Things which are currently highly visible to the source code become
>abstracted implementation details that normal source code simply doesn't
>care about or have to deal with.

It's certainly easier to think of C as a high(er) level macro
assembler, but whether or not that's a good mental model is
debateable. Personally, I wouldn't put a lot of new C code into
a kernel that wasn't already implemented in C post about 2018 or
so.

- Dan C.

On Thursday, July 20, 2023 at 8:20:43 AM UTC-4, Simon Clubley wrote:
> On 2023-07-19, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> > On 7/19/2023 1:32 PM, Simon Clubley wrote:
> >> On 2023-07-19, Dave Froble <da...@tsoft-inc.com> wrote:
> >>> On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
> >>>> On 7/18/2023 9:25 PM, Dave Froble wrote:
> >>>>> Do you also claim that the executable code would also be smaller?
> >>>>
> >>>> No.
> >>>
> >>> Then, what would be the benefit?
> >>
> >> For one thing, if you didn't have to worry about the Macro-32 and
> >> Bliss crap, the VMS port would have been completed years ago.
> >
> > Are you sure?
> >
> > It is not my impression that the various VMS ISA migrations has
> > caused rewrite of lots of Macro-32 and Bliss.
> >
> > My impression is that:
> > - they create the Macro-32 and Bliss compilers for the new platform
> > - they compile the old Macro-32 and Bliss code dating back from the
> > 70's and 80's
> > - the new code get written in C (plus a little bit of native
> > assembler where needed)
> >
> You have missed what I am saying above, so I may have been too subtle.
> Let me reword it: If VMS didn't have any Macro-32 or Bliss code in it,
> and didn't need to support them as application level programming languages,
> VMS would look much more internally like any another OS written in C does,
> and the port would have been completed years ago.
Ah, so you are commenting on the choices made in 1977. C wasn't on the menu
of implementation languages.

Even if there was a C compiler, the PDP-11/RSX legacy of the designers would
probably still have itemlists, descriptors, etc. all with their 32-bit pointer bias. And
also for FABs/RABs/etc. Just having a C compiler doesn't make you "think"
differently.

For BLISS, SDL makes good macros to let you deal with structures in abstractions.
You don't have to know sizes or offsets to use the fields. For example, from inside
Pascal frontend. The definition of SYM_Symbol_Table_Entry comes from SDL. It
was SDL that computed the field sizes/offsets/positions into the .REQ file.

LOCAL Sym : SYM_Symbol_Table_Entry;

IF .Sym[SYM_CLASS] EQL SYM_K_Function
THEN
! something for function
ELSE
! something for not function

or

Sym[SYM_BLOCK_NUMBER] = .Sym[SYM_BLOCK_NUMBER] + 1;

etc.

BLISS can be awkward for coding up following pointers and accessing fields but there are
macros we use and BLISS syntax for doing that.

SDL also makes macros for Macro source, but you are correct that the sizes get encoded
into the VAX instruction (ie, MOVW vs MOVL vs MOVQ). Or if some field is encoded into
the middle of a FLAGS field. Macro programmers can get sloppy in their usage. So the
Macro code has been limited to extend/modify data structures. For ones that are still the
same since 1977 (think FAB/RAB/descriptors), the MOVL from 1977 is just fine today.

And looking at GEM sources (no Macro code), I see way more things like

LOCAL SYM : REF GEM_SYMBOL_NODE INITIAL(0);

and uses of

RETURN .GEM_TB_IS_DECIMAL_TYPE[.SYM[GEM_SYM_DATA_TYPE]]

I don't see many random "pointers to integer" or "pointer to char"" (which isn't
easy to write in BLISS, you end up with REF VECTOR[,LONG] or REF VECTOR[,BYTE]
but have to keep using [0] all over the place)

And the C code has things like

GEM_ENTRY *entry = (GEM_ENTRY*) elfst_entry->Node();

if (entry == NULL) return NULL;
if (entry->Kind() != GEM_NODE_K_SYMBOL) return NULL;
if (entry->Subkind() != GEM_SYM_K_ENTRY) return NULL;

return entry->EntrySignature();

Neither have any size/position dependencies (other than BLISS-32 only does
32-bit values and switching to BLISS-64 sometimes can be tricky)

I do see several

GEM_UINT32*

declarations in the C code. Writing in C does "encourage" things like pointer to
int or pointer to char more than BLISS does (at least in my opinion)

On 2023-07-20, Dave Froble <davef@tsoft-inc.com> wrote:
> On 7/20/2023 8:20 AM, Simon Clubley wrote:
>
>> It doesn't take 9 years to port Linux to a brand-new architecture, even
>> if you first have to implement the compilers for that brand-new architecture.
>
> Not the same thing at all.
>

Why ? I'm talking about how long it is taking.

> For those with Linux apps, there are already platforms that can be used. The
> same cannot be said for VMS. So VMS has additional needs, as in needed, and
> just might be more work. Linux however, just isn't needed on additional platforms.
>
> I can also imagine a "brand-new architecture" where a port of Linux just might
> not be so easy.
>

People didn't have much of a problem getting it onto RISC-V, which is
indeed a brand-new architecture that also needed major compiler work.

Simon.

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

On 2023-07-20, John Reagan <xyzzy1959@gmail.com> wrote:
> On Thursday, July 20, 2023 at 8:20:43?AM UTC-4, Simon Clubley wrote:
>> You have missed what I am saying above, so I may have been too subtle.
>> Let me reword it: If VMS didn't have any Macro-32 or Bliss code in it,
>> and didn't need to support them as application level programming languages,
>> VMS would look much more internally like any another OS written in C does,
>> and the port would have been completed years ago.
> Ah, so you are commenting on the choices made in 1977. C wasn't on the menu
> of implementation languages.
>

Unix had been around for several years by then.

Other operating systems had been written in various higher-level languages
before that.

It really is a pity that VMS didn't come along several years later
when attitudes to writing full systems in assembly language had
well and truly changed.

Simon.

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

In article <u9dslr$385j1$1@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
> On 2023-07-20, Dave Froble <davef@tsoft-inc.com> wrote:
> > I can also imagine a "brand-new architecture" where a port of
> > Linux just might not be so easy.
> People didn't have much of a problem getting it onto RISC-V, which
> is indeed a brand-new architecture that also needed major compiler
> work.

There are network externalities here. The things that Linux assumes about
a machine are fairly simple. They probably amount to something like:

* Byte addressing. Endianness is not important.
* Flat address space big enough for any single program.
* Some kind of memory protection system. Paging is optional.
* Some kind of interrupt priority system.
* User and supervisor modes.

Designing a new architecture that cannot meet these requirements means
you /must/ design a new operating system for it, and you cannot readily
take advantage of the large amounts of useful open-source software that
are out there. So nobody will do that, unless they have a really
compelling idea about computing that can't be made compatible with Linux
requirements. There don't seem to be many of those coming along at
present.

Note that these requirements are a subset of VMS' requirements, and all
of VMS' hardware platforms are fully capable of running Linux. The only
one where that hasn't been done on any scale is VAX, simply because VAX
was already on the way out when Linux started to grow out of its original
x86 niche.

I also read comp.arch, where there is a community of people who design
new processor architectures, either professionally or for fun. There are
at least two people there who as hobby projects have designed a new
architecture, implemented it in an FPGA, and got Linux running on it,
either by themselves or with one or two people's help. I don't know how
long it's taken them, but I think it's less than nine years.

The strangest new architecture that gets discussed there regularly is The
Mill <https://millcomputing.com/>. This has no registers in the
conventional sense, and two program counters per thread, but the
operating system they're porting to it is Linux.

John

In article <memo.20230721201301.21172K@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <u9dslr$385j1$1@dont-email.me>,
>clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>> On 2023-07-20, Dave Froble <davef@tsoft-inc.com> wrote:
>> > I can also imagine a "brand-new architecture" where a port of
>> > Linux just might not be so easy.
>> People didn't have much of a problem getting it onto RISC-V, which
>> is indeed a brand-new architecture that also needed major compiler
>> work.
>
>There are network externalities here. The things that Linux assumes about
>a machine are fairly simple. They probably amount to something like:
>
>* Byte addressing. Endianness is not important.
>* Flat address space big enough for any single program.
>* Some kind of memory protection system. Paging is optional.
>* Some kind of interrupt priority system.
>* User and supervisor modes.
>
>Designing a new architecture that cannot meet these requirements means
>you /must/ design a new operating system for it, and you cannot readily
>take advantage of the large amounts of useful open-source software that
>are out there.

It strikes me that these two things (an OS for an "unusual"
architecture lacking one or more of the requirements listed
above, and the ability to make use of the large body of
open-source software) are mostly orthogonal. Indeed, many
useful OSS packages are available for a variety of wildly
different systems.

Sure, things that are Linux-specific (or Unix/POSIX-specific
more generally) won't be readily portable to other systems, but
the universe of useful open source userspace software is very
large, and much of it could run on, say, a machine that doesn't
support interrupts or user/supervisor modes.

>So nobody will do that, unless they have a really
>compelling idea about computing that can't be made compatible with Linux
>requirements. There don't seem to be many of those coming along at
>present.

I'm not sure about that; we see lots of accelerator processors
that don't implement a traditional ISA and they run lots of
stuff.

>Note that these requirements are a subset of VMS' requirements, and all
>of VMS' hardware platforms are fully capable of running Linux. The only
>one where that hasn't been done on any scale is VAX, simply because VAX
>was already on the way out when Linux started to grow out of its original
>x86 niche.
>
>I also read comp.arch, where there is a community of people who design
>new processor architectures, either professionally or for fun. There are
>at least two people there who as hobby projects have designed a new
>architecture, implemented it in an FPGA, and got Linux running on it,
>either by themselves or with one or two people's help. I don't know how
>long it's taken them, but I think it's less than nine years.
>
>The strangest new architecture that gets discussed there regularly is The
>Mill <https://millcomputing.com/>. This has no registers in the
>conventional sense, and two program counters per thread, but the
>operating system they're porting to it is Linux.

I'll believe in the Mill when I see it. :-D

- Dan C.

On 7/20/2023 8:20 AM, Simon Clubley wrote:
> On 2023-07-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/19/2023 1:32 PM, Simon Clubley wrote:
>>> On 2023-07-19, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 7/18/2023 10:01 PM, Arne Vajhøj wrote:
>>>>> On 7/18/2023 9:25 PM, Dave Froble wrote:
>>>>>> Do you also claim that the executable code would also be smaller?
>>>>>
>>>>> No.
>>>>
>>>> Then, what would be the benefit?
>>>
>>> For one thing, if you didn't have to worry about the Macro-32 and
>>> Bliss crap, the VMS port would have been completed years ago.
>>
>> Are you sure?
>>
>> It is not my impression that the various VMS ISA migrations has
>> caused rewrite of lots of Macro-32 and Bliss.
>>
>> My impression is that:
>> - they create the Macro-32 and Bliss compilers for the new platform
>> - they compile the old Macro-32 and Bliss code dating back from the
>> 70's and 80's
>> - the new code get written in C (plus a little bit of native
>> assembler where needed)
>>
>
> You have missed what I am saying above, so I may have been too subtle.
> Let me reword it: If VMS didn't have any Macro-32 or Bliss code in it,
> and didn't need to support them as application level programming languages,
> VMS would look much more internally like any another OS written in C does,

That is a point you have made several times.

> and the port would have been completed years ago.

Why?

It is not faster to recompile Macro-32 and Bliss with no changes
than to recompile C with no changes.

See above.

Arne

On 7/20/2023 8:49 AM, Simon Clubley wrote:
> I get the impression that you have had to spend a lot of effort to
> duplicate low-level behaviour in a way that simply isn't a concern
> with other operating systems due to the need, especially, to support
> Macro-32 and ensure that code written at this low-level, and which
> uses the various idioms as a result, continues to work.

I believe Macro-32 is a relative simple compiler. And when they got
that then they can compile the existing Macro-32 code.

Not a reason for delay.

> No, the real benefits of C include the ability to use abstractions in
> your code which make the code a lot quicker to write, where you can
> focus much more on what you want, instead of having to lay out in
> minute detail how to do it, and as a result your code also becomes
> much more reusable and portable.
>
> You can design complex data structures much more easily and get much
> more help from the compiler in finding errors in your code.

????

I believe that VSI is mostly reusing existing Macro-32 code
and writing new code in C.

So not relevant.

> For one really simple example, in C, you ask for a pointer and let the
> compiler implement the pointer behind the scenes. Ie: you write:
>
> char *ptr;
>
> instead of:
>
> uint32_t ptr;
>
> In C, your normal application code works the same, regardless of whether
> that pointer is 32-bits or 64-bits. If the lowest-level language in VMS
> was C, this is what the RMS interface would conceptually look like:
>
> struct {whatever}_rms_rab_t *rab;
>
> instead of the current setup. Likewise for itemlists and other structures.
>
> Things which are currently highly visible to the source code become
> abstracted implementation details that normal source code simply doesn't
> care about or have to deal with.

You have posted that numerous times.

It means that changing from 32 bit pointers to 64 bit pointers is
way easier in C than in Macro-32.

But based on what we know about the port, then VSI has not changed
the VMS kernel from 32 bit pointers to 64 bit pointers (aka moving
everything from S0 and S1 to S2).

So it is not relevant for the topic.

Arne

On 7/20/2023 8:49 AM, Simon Clubley wrote:
> I keep looking at why the port is currently at 9 years and counting
> compared to how long it takes to port Linux to a brand-new architecture
> and keep wondering why it is taking so long.
>
> There are some things you have had to implement, such as KESU emulation,
> that Linux doesn't have to deal with, but I have a hard time seeing why
> that would take more than a few months to design and implement.

The 9 years do raise some questions, but some answers are known.

Why has Itanium->x86-64 taken longer time than VAX->Alpha and
Alpha->Itanium?

It has been explained that is because VSI got fewer engineers than
DEC and HP.

Why does it take so long when any CS student can do a port of some
nix flavor in a semester?

VMS has 2 constraints:
- it has to be commercial grade (rock solid, complete etc.)
- it has to be 100% compatible

Everybody that has done software development knows that it
takes 10-100 times more time to do a commercial grade
production ready product than an experimental test product.

And 100% compatibility instead of just 98% compatibility
is also a burden that prevents the easy shortcuts.

Why does VMS port take longer than a Linux port?

First we need to make sure that the Linux port is
comparable per above. Some of the few that comes to my
mind is IBM's ports to Power and mainframe. I have
no idea how long time IBM spent on that.

But let us assume IBM did spend less time than VSI
on VMS x86-64.

VMS is probably less portable than Linux in design.

VMS was designed in parallel with VAX - the OS people
could ask the HW people for what they needed.

The 64 bit port to Alpha was also to something
controlled by DEC and they could create PALcode
for what they needed.

Linux was designed in a world where the HW specs
were externally given.

Now VMS is in that world as well - VSI cannot call
Intel/AMD and ask to get a few instructions added.

It is not just the only 2 modes.

The VSI people have also mentioned the lack of probe
as an issue.

There are probably a number of issues in this category -
let us say somewhere between 10 and 100.

Add that work on top of all the above and the 9 years
start to look less surprising.

Arne

On 7/21/2023 8:21 AM, Simon Clubley wrote:
> On 2023-07-20, John Reagan <xyzzy1959@gmail.com> wrote:
>> On Thursday, July 20, 2023 at 8:20:43?AM UTC-4, Simon Clubley wrote:
>>> You have missed what I am saying above, so I may have been too subtle.
>>> Let me reword it: If VMS didn't have any Macro-32 or Bliss code in it,
>>> and didn't need to support them as application level programming languages,
>>> VMS would look much more internally like any another OS written in C does,
>>> and the port would have been completed years ago.
>> Ah, so you are commenting on the choices made in 1977. C wasn't on the menu
>> of implementation languages.
>
> Unix had been around for several years by then.
>
> Other operating systems had been written in various higher-level languages
> before that.
>
> It really is a pity that VMS didn't come along several years later
> when attitudes to writing full systems in assembly language had
> well and truly changed.

When DEC made the decisions back in the late 70's using assembler
and a proprietary low level language was not unusual.

And C was not that big a language yet. I don't even think
VAX C was available for the first VMS versions.

If DEC had been able to see into the future then they
may have gone with C.

But ...

Arne

On 7/19/2023 10:32 PM, John Reagan wrote:
> On Wednesday, July 19, 2023 at 1:32:25 PM UTC-4, Simon Clubley wrote:
>> It's also a hell of a lot easier, quicker, and more robust, to
>> write something in C than it is in Macro-32 or Bliss.

> As for "easier, quick, robust", that's a matter of skill. The real benefits
> of C over BLISS/MACRO include "floating point" and provided I/O package.

I believe that it requires more skills to be good at
Macro-32 than to be good at C.

But OK the minimum skills to be allowed to write kernel
code in C (as opposed to application code in C) are
probably sufficient to also make them Macro-32 capable
as well.

It still takes more time to read Macro-32 than C.

And while your new hires (for OS development) already
knows C then I guess nobody below 50 knows Macro-32.

Arne

On Sat, 2023-07-22 at 10:48 -0400, Arne Vajhøj wrote:
> If DEC had been able to see into the future then they
> may have gone with C.

IF they had, VMS would have had a shitload of exploits against it.
Thankfully they didn't and avoided a lot of issues that plagues most
operating systems written in C.
--
Tactical Nuclear Kittens

On 7/22/2023 11:06 AM, Single Stage to Orbit wrote:
> On Sat, 2023-07-22 at 10:48 -0400, Arne Vajhøj wrote:
>> If DEC had been able to see into the future then they
>> may have gone with C.
>
> IF they had, VMS would have had a shitload of exploits against it.
> Thankfully they didn't and avoided a lot of issues that plagues most
> operating systems written in C.

Maybe.

C is very unsafe compared to almost all other high level
languages.

But I don't think it is more unsafe than Macro-32.

:-)

Anyway: Windows and Linux has not failed commercially
due to the buffer overflows.

:-)

Arne