[Info-vax] CRTL and RMS vs SSIO

[Stephen Hoffman]

On 2021-10-13 18:01:54 +0000, Simon Clubley said:

> On 2021-10-12, Lawrence D?Oliveiro <lawrencedo99 at gmail.com> wrote:
>> On Wednesday, October 13, 2021 at 6:57:05 AM UTC+13, Simon Clubley wrote:
>>> No other operating system needs to support assembly language as an 
>>> application programming language.
>> 
>> I don't think support for assembly language is the issue -- assembly 
>> language can still be useful and relevant in app code today, for 
>> example in video encoding. Here's what I think the issue is about: 
>> 'control blocks'.
>> 
> 
> The difference is the other operating systems don't need to support 
> calling system services (for example) from assembly language and if you 
> try it you are on your own. On VMS it does and it's supported as such.
> 
> Unfortunately.
> 
> (And yes, it's a product of the time VMS was designed in along with the 
> heritage that VMS inherited.)


Macro32 isn't particularly limited in what it can call. Particularly as 
compared with BASIC and other 32-bit apps and 32-bit APIs/ABIs present 
on OpenVMS.

Macro32 has long had some 64-bit capabilities: $PUSH_ARG64, $CALL64, 
.ENABLE QUADWORD, .CALL_ENTRY QUAD_ARGS=TRUE, etc.

Underneath your references to Macro32 too, the 1970s-style structure 
definitions inherently mean any API or ABI changes will require changes 
to app source code, across languages.

Any incompatible changes that will then effect Macro32 apps, and all 
other apps calling system services and RMS services.

In C, that's going to entail changes to anything using char, short, 
int, long long, int32_t, uint64_t, etc. with changed APIs.

These changes can absolutely happen—though not compatibly—and it'll 
take a dozen years and probably more to migrate even the 
actively-maintained apps across VSI and ISV and end-user apps.

I'd tend to aim for object APIs as the replacement here too, as that 
trades off some run-time performance—not that itemlists were ever known 
for performance-friendliness—for more flexible and extensible 
interfaces later.

Not that I'd expect to ever meet Macroo32. 🤪

Again, you're dancing around the limits of a 1970s-era API/ABI design 
and the general goal of upward-compatibility; of minimal disruptions to 
existing 32-bit apps. Not any limits specific to Macro32.

The larger-scale and longer-term "fix" is a migration to a 64-bit only 
environment, with the existing 32-/64-bit environment preserved for a 
~decade pending deprecation, and eventually then removal. But that's 
not happening.

And to be absolutely clear, I do not expect any substantial new Macro32 
compiler work or features past what is needed for the port, and I do 
not expect existing Macro32 apps will see anything more than 
incremental work in existing Macro32.

TL;DR: it's the "control blocks" and the API design.


-- 
Pure Personal Opinion | HoffmanLabs LLC