[Info-vax] Hard links on VMS ODS5 disks

[John Reagan]

On Thursday, July 20, 2023 at 8:20:43 AM UTC-4, Simon Clubley wrote:
> On 2023-07-19, Arne Vajhøj <ar... at vajhoej.dk> wrote: 
> > On 7/19/2023 1:32 PM, 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: 
> >>>>> 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.