[Info-vax] Hard links on VMS ODS5 disks

Simon Clubley clubley at remove_me.eisner.decus.org-Earth.UFP
Wed Jul 19 13:32:21 EDT 2023


On 2023-07-19, Dave Froble <davef 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.

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 at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.



More information about the Info-vax mailing list