[Info-vax] VMS and the embedded world, was: Re: PowerX Roadmap - Extended beyond 2020

[Bill Gunshannon]

On 10/24/16 4:13 PM, Simon Clubley wrote:
> On 2016-10-24, John Reagan <xyzzy1959 at gmail.com> wrote:
>>
>> For those who are interested.
>>
>> For BLISS, is is the powerful macro language built into the
>> frontend.  It is context-sensitive so even trying to write a
>> pre-processor in some more expressive language (Perl, Python, etc.)
>> makes is a difficult task.  For example, when expanding an iterative
>> macro, the compiler has to decide on a separator (ie, does it insert a
>> free "," between times or something else).  That depends on where in
>> the BLISS language the macro is being expanded.
>>
>
> I don't have any BLISS experience so I am in no position to judge
> the issues here.
>
>> For Macro, it is mostly the fact that you can jump between routines.
>> You can come into routine A, jump to B, jump to C, indirectly jump to
>> D or E, and finally return from F.  That is difficult to express in C
>> (or just about anything else).  We had a translator company try years
>> ago with such a piece of Macro, and the resulting C looked like:
>>
>> int B(int R0, int R1, int R2, you get the idea...);
>>
>> and kept passing those parameters from routine to routine.
>>
>
> That C code makes me go ouch. :-)

The description of the Macro really makes me wonder where people get the
idea that C is the language that lets programmers write bad code.

>
> Apart from the obvious inefficiency involved, the immediate thing
> which jumps out hard is to wonder if passing as int causes some
> unsigned data to wrongly be used as signed data.

That can be done in any language.  The results vary.  My last COBOL
gig (just a couple years ago) had me going over a bunch of programs
after I found a bunch of calculations where the intermediate results
were all stored in unsigned data items. Place was really pleased with
themselves that none of the jobs (over a period of many years) ever
went over estimate.  Oops.

>
> I would hope that this company gave _very_ careful attention to the
> _exact_ instructions used in the MACRO-32 source when generating the
> C code to make sure that unsigned data really did get treated as
> unsigned data.
>
> Otherwise that could have been a wonderful source of security
> vulnerabilities.

I don't see the security vulnerability (but then, I can't see the actual
code) but I can see where the results would frequently (if not always)
be just plain wrong.

>
>> The Macro-32 cross-jumping is a real pain on both Alpha and Itanium.
>> On Alpha, all of those routines need their R27 linkage pointer to be
>> the same.  On Itanium, all of those routines need their out0-out7
>> registers to be the same so they all need their 'alloc's to be the
>> same.  The Macro compiler has to build an elaborate flow graph and
>> walk it several times forward and backward to look for available
>> registers in basic blocks, lifetimes of VAX condition codes, and which
>> PUSHLs are putting values into parameters vs actually building some
>> data structure on the stack.  And on Itanium, some of those PUSHLs
>> might involve NaTs and need even more special-handling.
>
> And it's reading about stuff like this which makes you realise why
> it takes time to port VMS to a new architecture.

I would certainly hope the example above is not taken from somewhere
in VMS.

bill