[Info-vax] Assembly languages, was: Re: Listeners in VMS Basic

[Stephen Hoffman]

On 2021-07-13 13:06:46 +0000, Simon Clubley said:

> On 2021-07-12, Chris Townley <news at cct-net.co.uk> wrote:
>> 
>> When I joined out development team in 1997 (after years running an 
>> operational unit using the software) I stated that I was fine with a 
>> high level language, but I would refuse to use or learn macro -my only 
>> experience of a low level language was Z80, and I failed then, and did 
>> not want to go through that  again. This was accepted.
>> 
> 
> I have worked with multiple assembly languages. Examples are PDP-11, 
> VAX, Alpha, MIPS, ARM, x86 and Z80.

Outside of debugging and very targeted applications, assembly language 
has largely faded, all umbrage from the 1980s back when that transition 
started aside. And there was a ~decade of umbrage.

> I am also of the opinion that anyone writing full production 
> applications in assembly language these days are either a poser or 
> someone creating a little "job security".

Or a developer that doesn't have access to the necessary compilers, as 
has happened at several engagements. When what you have is one HLL 
compiler as various sites do, you'll either need the site to buy 
another compiler, or you use what you have.

But yes. Working toward better portability is a Good Thing for all 
critical production apps.

But whether that incremental work is in the budget?

This also all ties back into getting Lua or some other newer languages 
into the base OpenVMS distro, too.

> There are plenty of reasons why little bits of assembly language are 
> still required for some specific low-level things, but decades have 
> passed since it was appropriate to write full applications in them.

Ayup. And there are still some very big tracts of Macro32 around at 
various sites, and little budget to change it. And fewer and fewer 
folks that know Macro32. Which means incremental replacement, when and 
where that's feasible.

> The same comments apply to Bliss BTW. The new low-level assembly 
> language is called C and has the advantage of being (mostly) portable 
> between multiple architectures without having to rewrite your code.

Having done a whole lot in both, Bliss has vastly better macro support 
than does C, but I wouldn't prefer to use Bliss otherwise.

Bliss itself hasn't seen updates for ~30 years past porting and 
bugfixes, and it's missing some features now common and expected 
else-language.

> VSI rewriting parts of VMS in C as required is something I strongly approve of.

DEC started new OpenVMS work in C, and substantial rework in C, back in 
the 1990s.

There were a few exceptions to that, such as a big new hunk of Ada that 
is now being rewritten into C.

That translation into C had been the original plan, but that 
translation became necessary at VSI.

As for rewriting, I'm interested to see what Hex-Rays or Ghidra does 
with assembler-to-C translations, as (if) those tools become available 
with OpenVMS now arriving on x86-64. Because we're probably not going 
to see a Macro32 to C translator anytime soon. And yes, translated code 
is awful. But then I've used some C refactoring tools that do well with 
cleaning up C code and its control flow.

> And before anyone pulls me up about the Bliss comment, even _C_ is much 
> more type-safe than Bliss is.

Bliss doesn't particularly care.

Nor does Macro32.

Nor K&R era C, for that matter.

Recent C at least gets somewhat more snippy about type conversions, 
particularly when the locally-suggested qualifiers are enabled. 
Something akin to: /WARN=( ENABLE=( NOC99, OBSOLESCENT, DEFUNCT, 
QUESTCODE, ...), DISABLE=(...))

It'll be interesting to see the rocks that clang with C17 support will 
kick over in some codebases.

> I do wish however that a more type-safe alternative than C had taken 
> hold for low-level systems programming.

There wasn't a better alternative for system programming and 
kernel-mode code available back in the 1990s, when this DEC shift from 
Macro32 and Bliss to C happened. And even now, I'm not sure there are 
significantly better system-programming alternatives for C to this day, 
though there are certainly much better options available now than those 
that existed a quarter-century ago. Rust is among the few that I'd 
consider, here.





-- 
Pure Personal Opinion | HoffmanLabs LLC