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

[Chris Townley]

On 13/07/2021 16:30, Stephen Hoffman wrote:
> 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.
> 

We had the HLL compilers, but the macro was mostly for speed 
improvements going back to PDP and early VAX. Some of the tools were 
very good, but could easily been written in HLL later - I did just that 
when I needed to enhance the functionality of Macro code - using the 
external documentation rather than the code, which was unreadable to me!

Chris


-- 
Chris