[Info-vax] System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was

[VAXman- at SendSpamHere.ORG]

In article <nkhaf5$5la$1 at dont-email.me>, David Froble <davef at tsoft-inc.com> writes:
>Craig A. Berry wrote:
>> On 6/23/16 11:26 AM, David Froble wrote:
>>> Simon Clubley wrote:
>>>> On 2016-06-22, David Froble <davef at tsoft-inc.com> wrote:
>>>>> Paul Sture wrote:
>>>>>> On 2016-06-22, Simon Clubley
>>>>>> <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>>>>> On 2016-06-21, David Froble <davef at tsoft-inc.com> wrote:
>>>>>>>> John Reagan wrote:
>>>>>>>>> RMS wins the trifecta of languages. You'll find Macro, BLISS, and C
>>>>>>>>> in the source directory.
>>>>>>>> WHAT !!!
>>>>>>>>
>>>>>>>> No Basic ???
>>>>>>> Sorry David, but Basic is not a system implementation/programming
>>>>>>> language. :-)
>>>>>>>
>>>>>> My memories of RSTS suggest that BASIC got used *everywhere*... :-)
>>>>>>
>>>>> Good one!
>>>>>
>>>>
>>>> Not really. :-)
>>>>
>>>> You can't use any version of Basic I've come across to write a kernel
>>>> mode device driver or the kernel itself.
>>>>
>>>>> Take that Simon, who just recently mentioned RSTS/E ....
>>>>>
>>>>> Ok, back to reality.  I do believe the RSTS/E OS was Macro-11
>>>>
>>>> True. Examples of what I consider to be a system implementation
>>>> language (SIL) are C, Ada and the odd version of Pascal (such as the
>>>> version used to write VAXELN).
>>>>
>>>> Examples of languages which are not SILs are Basic, COBOL and PHP.
>>>>
>>>> Simon.
>>>>
>>>> PS: If DEC had fixed up some issues with Pillar and implemented it,
>>>> that would have made a good SIL (better than C IMHO). Unfortunately,
>>>> DEC never followed through with Pillar.
>>>>
>>>
>>> Any language, if appropriate capabilities are implemented, can be so
>>> used.  I seem to recall that DEC's C needed some work before it could be
>>> used.  Put the same capabilities in Basic, and it would do just as
>>> well.  Well, maybe even better.
>>>
>>> It's all just 1's and 0's ....
>> 
>> You're missing quite a bit there. For one thing, with BASIC and most
>> (all?) other HLLs on VMS, you are making RTL calls without realizing it.
>> In other words, the compiler uses things like OTS$CVT_L_TB or
>> STR$GET1_DX and friends to implement language statements that are not
>> explicitly calling functions or subroutines. Unless all the RTLs
>> involved satisfy all the necessary requirements for reentrancy, thread
>> safety, atomicity, and probably other things I'm forgetting, then you
>> can't safely write inner mode code in such a language.
>> 
>> Could a BASIC be implemented that satisfied the requirements? Possibly,
>> but you might not want to use it. I don't know exactly what would go
>> missing, but as a hypothetical, say you had a BASIC that had no WHEN
>> ERROR clause, could not do dynamic strings, and had no language-level
>> support for I/O such that you had to use more primitive interfaces to do
>> all I/O. Would you still be advocating for such a language?
>> 
>> 
>> 
>
>Without getting into the details, a version / subset / whatever of any language 
>could be implemented with the necessary capabilities and restrictions.  Would it 
>be simple?  No.
>
>The current Basic uses RTL calls extensively.  They are there, and it's simple 
>enough.  Is that the only way to do things?  Of course not.  But it's adequate 
>for the current uses of Basic.
>
>Is it worth doing with Basic at this time?  No, not really.  There would be the 
>satisfaction of rubbing some noses in it (Hi Steve), but, that would be some 
>really labor intensive satisfaction.
>
>Sometimes some things just don't mix well.  Not sure why I've had such a problem 
>with C.  But I do.  I'd have an easier time doing something in Macro-32 than C. 
>  I'm sure I'm in a very small minority.  But, that's where I am.

I find that I can do *VMS* things more easily in Macro than in C but that's
because I was doing those things before C was usable as a system programming
lingo on VMS.  I would help, somewhat, if C had a decent macro capability. 



>Also note, it's my impression that not all parts of C can be used in kernel mode 
>work.  Could be wrong.  Don't think so.

Most of the C RTL can be used because it's been made resident in the kernel.
The same could be done for other lingos too but it hasn't.  There are several
special C routines for use in VMS system programming too.  Because of a lack
of a decent macro capability, certain things -- device driver strucutres come
to mind -- are provided by some special setup procedures/routines.  When I do
use C, I often use/call system routines in lieu of the C RTL routines such as
those for manipulating string (dynamic strings, especially) because C's view
of a string is simply a pointer to textual data with a null termination.  If
I use command definition language, for example, I will supply dynamic string 
descriptors to CLI$ calls and allow VMS to allocate what's necessary for the
string data.  The purists will argue, "that's not portable" but then, system
code for VMS is NOT likely to be ported to *ix, is it?

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.