[Info-vax] Userland programming languages on VMS.
Simon Clubley
clubley at remove_me.eisner.decus.org-Earth.UFP
Thu Feb 3 09:15:35 EST 2022
On 2022-02-02, Arne Vajhøj <arne at vajhoej.dk> wrote:
> On 2/2/2022 4:34 PM, Bill Gunshannon wrote:
>> On 2/2/22 14:30, Arne Vajhøj wrote:
>>> On 2/2/2022 1:41 PM, Simon Clubley wrote:
>>>> They were also very insightful in that the minimum application
>>>> programming
>>>> language they supported was also C. These factors laid the groundwork
>>>> for the future use of Unix across a large range of architectures and
>>>> was directly responsible for its rise to the position it gained.
>>>
>>> I believe that assembler has always been supported on Unix.
>>>
>>> With the traditional Unix C tool chain of compiler driver calling
>>> preprocessor, actual compiler, assembler and loader then it is
>>> not even possible to compile on a system without the assembler.
>>
>> I don;t think he was saying they had no assembler, they certainly did
>> and it got used. I have used it myself. And looking at assembler
>> output from the compiler is often a big help when trying to locate
>> and fix bugs. He just meant that the OS is not written in assembler.
That's right. The backend of the compiler gets given the IR code from
the front end after the front end parsed the user's source code and it
doesn't care what the code itself is doing or what part of the OS the
source code is interacting with.
The assembly language here is only a step along the way of creating the
final object code for the linker to use and is something that's private
to the compiler toolchain.
And yes Bill, you are correct in that the assembly language can be useful
in finding bugs, including compiler bugs. There's an Ada AI that's a direct
result of me looking at such code.
IOW, the assembly language is generated by the compiler and has absolutely
no meaning to the operating system itself.
>
> That is how you read:
>
> "the minimum application programming language they supported was also C"
>
> ?
>
That's exactly how you should read it Arne.
In VMS, I can point you to the operating supplied headers that allow
application programs to be written in Macro-32 and call VMS system
services, including all the structure definitions. That makes Macro-32
a supported language for application programming (unfortunately).
In Linux, there are no such headers because assembly language is not
a supported application programming language. (And /usr/include/asm/
is _NOT_ about writing application programs in assembly language. :-) )
>> I would have to go back an look but I am pretty sure even after the
>> advent of the C based Unix there were still pieces in assembler for
>> quite some time. I do not believe any of the current BSD's still
>> have any except maybe 2.11 on the PDP-11.
>
> I would have thought any OS needed a few assembler code files
> or some C code files with ASM directives or some C code with
> system specific pseudo functions mapping to native
> instructions. To get some of really HW specific stuff done.
>
That's for extremely low-level stuff such as initial boot code or
interrupt dispatch code that dispatches to a C language interrupt
handler. Even when working on kernel code, most people never even
go anywhere near such code.
About the only time you would see assembly language in application
programs is as tiny inline fragments called from a HLL if you needed
direct access to a specific specialist CPU register (for example)
and then you (and not the OS) are responsible for that assembly language.
Simon.
--
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
More information about the Info-vax
mailing list