[Info-vax] Hard links on VMS ODS5 disks

Dave Froble davef at tsoft-inc.com
Wed Jul 19 14:00:09 EDT 2023


On 7/19/2023 1:32 PM, Simon Clubley wrote:
> 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, 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 at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486



More information about the Info-vax mailing list