[Info-vax] Hard links on VMS ODS5 disks

[Simon Clubley]

On 2023-07-19, John Reagan <xyzzy1959 at 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... at 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 at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.