[Info-vax] Learning VMS application programming

[Stephen Hoffman]

On 2014-09-07 14:00:38 +0000, Phillip Helbig---undress to reply said:

> In article <dh3udb-cop1.ln1 at news.chingola.ch>, Paul Sture
> <nospam at sture.ch> writes:
> 
>>>>>> I never saw Fortran used for systems programming before.
>>>>> 
>>>>> Fortran is not used for system programming on VMS.   It's an 
>>>>> application-programming language.
>>>>> 
>>>>> C, Bliss and Macro32 assembler are most commonly used for system-level 
>>>>> programming on VMS.
>>> I'm using "system programming" to refer to "operating system 
>>> programming", as differentiated from application systems.  That is, I'm 
>>>  referring to the languages used for OpenVMS device drivers, 
>>> kernel-mode code, and related programs.
> 
> While that might be the case,

Might?  No.  I can say with certainty that I was referring to 
inner-mode programming when I was using the phrase "system 
programming".  No "might" needed there.

>  I don't think there is any inherent reason why Fortran could not be 
> used for system programming on VMS, at least with VMS-specific 
> extensions (which applies to the other languages as well).  One of the 
> strengths of VMS is that many languages are treated on an equal footing.

The common language environment does provide that, for user-mode code.

However, some programs and much of the older inner-mode VMS code can 
have different calling conventions, and has a different run-time 
context.

Until C was added as a system programming language, many of the kernel 
APIs were incompatible with the user-mode calling standard, and with 
access from languages other than Bliss and Macro32.    I'd expect there 
are still some hunks of the inner-mode code that use registers and 
stack-based calls and JSB interfaces, though most of the routines 
commonly used for system programming now use call-return patterns.  
You'll see support in C for these variant calling interfaces, too; see 
#pragma linkage and #pragma use_linkage for some related detail.

Beyond these calling linkages, you'll see various C built-ins that 
allow direct access to specific instruction set features within the 
code, and the ability to disable floating point instructions in the 
generated code, among other details.  What instructions are available 
and appropriate varies by the environment you're executing in, too — 
user-mode code has access to the full environment, where some 
inner-mode code may not.

> Apart from C, Bliss and Macro32, IIRC there is  some Pascal, some PL/I 
> and so on.

So submit an enhancement request for kernel-mode support for Fortran, 
COBOL, Java and whatever other languages are of interest.

FWIW, kernel-mode does mean different memory management requirements, 
which is why adding C required a new RTL.    Somebody'd have to look at 
the Fortran generated code (for calls to the OTS RTLs that get 
generated IIRC, for instance), and make sure all of those calls can be 
linked and can reference a kernel-mode-capable RTL.   It's not 
permissible or not secure to call user-mode RTLs from kernel-mode.   
Somebody'd also have to look at any padding in data structures and a 
variety of other minor details that showed up when the kernel-mode C 
work was reviewed and particularly around the kernel-mode C RTL.

Minimally, I'd expect a kernel-mode Fortran RTL and work around any 
other RTLs the Fortran compiler is referencing, and maybe (but 
hopefully not) a variant compiler switch and code generator for the 
inner-mode code.  (Given it's all GEM and C uses GEM, the code 
generator itself should be fine, though would still want a review.  The 
external references are key.)



But then this smells rather like the classic "technically feasible" 
versus "prudent investment of time and effort and budget" discussion 
trap, too.   Sure, inner-mode Fortran is technically feasible.  But who 
would use it, how much would they pay for this, and why don't we 
implement kernel-mode COBOL while we're at it?   Does VSI have other 
work that'll be higher on the schedule?


-- 
Pure Personal Opinion | HoffmanLabs LLC