On 2/3/2022 9:15 AM, Simon Clubley wrote:
> On 2022-02-02, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> That is how you read:
>>
>> "the minimum application programming language they supported was also C"

> 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.

I think defining "supported application programming language"
as having include files with constants used by system calls
a bit weird.

I believe there are lots of platforms where assembler had
to define constants themselves and assembler was still
used in applications. I don't think the LIB.MLB and STARLET.MLB
concept were common.

Arne

On 2/3/2022 9:15 AM, Simon Clubley wrote:
> On 2022-02-02, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/2/2022 4:34 PM, Bill Gunshannon wrote:
>>> 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.

I would expect some in process context switches as well.

And maybe something in the graphics driver.

> 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.

I think that is getting extremely rare today.

Arne

On Fr 04 Feb 2022 at 18:31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> It really is a pity there isn't a viable Wirth style language in the mix
> these days (_without_ mandatory uppercase keywords :-) ) that could
> be used in kernel code. Readability and strong type safety (and improved
> robustness in general) all in one language would sit very nicely with me.

Oberon is quite nice (and was the vasis for the OS of the same name) but
has uppercase keywords :-(
But a good editor can solve that problem.

'Andreas

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> You can write a full-blown parser in Macro-32 if you really want to.
> It doesn't mean that any sane person would want to do that when there
> are better languages available. :-)

I’m not sure a sane person would/should write a parser in any language,
given the effort that has been put into making toolkit ones available.

We implemented a pretty complex command language parser from Fortran on VAX
in the 1980s, but we made full use of available underlying facilities, such
as LIB$TPARSE. The state tables were defined in Macro-32, but just as data
not executable code.

Regards,

--
Paul at the paulhardy.net domain

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

> On 2/3/2022 9:15 AM, Simon Clubley wrote:
>> On 2022-02-02, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> That is how you read:

>>> "the minimum application programming language they supported was also C"

>> 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.

> I think defining "supported application programming language"
> as having include files with constants used by system calls
> a bit weird.

> I believe there are lots of platforms where assembler had
> to define constants themselves and assembler was still
> used in applications. I don't think the LIB.MLB and STARLET.MLB
> concept were common.

In Macro-10, there is a concept of "universal" files, in essence dumped symbol
tables from the assembly of a source file which consists only of definitions,
including macros.

Assembly language programs include these with the SEARCH pseudo-op; the
contents are added to the in-memory symbol table tree.

Again, I suspect that the Macro-32 designers were familiar with Macro-10...

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 2022-02-04 14:36, John Dallman wrote:
> In article <29ad12ab-b1a7-4a44-b1fa-3d12812cf603n@googlegroups.com>,
> xyzzy1959@gmail.com (John Reagan) wrote:
>> On Thursday, February 3, 2022 at 2:15:48 PM UTC-5, Simon Clubley
>>> You can write a full-blown parser in Macro-32 if you really want
>>> to. It doesn't mean that any sane person would want to do that when
>>> there are better languages available. :-)
>> Well, the Macro-32 parser is written in Macro-32.
>
> That sounds as if someone got carried away by the power of the VAX
> instruction set, as compared with previous instruction sets they'd used.

Meh. MACRO-11 is written in MACRO-11, as far as I know. And MACREL
(PDP-8) might actually have been written in PAL8.

I think this was pretty much the norm earlier...

Johnny

On 2022-02-02 22:34, Bill Gunshannon wrote:
> On 2/2/22 14:30, Arne Vajhøj wrote:
>> On 2/2/2022 1:41 PM, Simon Clubley wrote:
>>> No. It means that the Unix creators were _very_ insightful and _very_
>>> forward looking in the early 1970s when they rewrote Unix, including
>>> the kernel, in a mostly portable language that mostly decoupled the
>>> implementation from the architecture it ran on, while most other people
>>> still wrote their kernels, and maybe good portions of their userland
>>> as well, in assembly language.
>>
>> The idea of an OS mostly written in a HLL is not invented by Unix.
>
> Primos which predates VMS was written mostly in HLLs. Some pretty
> obscure ones, but HLLs just the same.  :-)

I think we just established that Unix also predates VMS, and is written
in HLLs.

But yes, Unix was also not first at doing that.

>> But I agree that they made the right decision.
>>
>>> 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.
> 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.

They do. There are simply some things that you can't do in C, no matter
how low level you think it is. So sometimes, assembler is still required.

>> And null terminated strings are not harder to do in assembler
>> than descriptor strings.
>
> Null terminated strings are common in MACRO-11.

That statement is slightly misleading. MACRO-11 provides the .ASCIZ
directive to create NUL-terminated strings. Beyond that, there is
nothing NUL-terminated in MACRO-11. Depending on what OS you are using,
you might find more uses of NUL-terminated strings, but that have
nothing to do with MACRO-11 itself.

I do believe that RT-11 is pretty fond of NUL-terminated strings, for
example. But RSX is not. Pretty much everything have length parameters,
with the exception of some user land libraries that might use
NUL-terminated strings.

Johnny

On 2022-02-05, Paul Hardy <p.g.hardy@btinternet.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> You can write a full-blown parser in Macro-32 if you really want to.
>> It doesn't mean that any sane person would want to do that when there
>> are better languages available. :-)
>
> I?m not sure a sane person would/should write a parser in any language,
> given the effort that has been put into making toolkit ones available.
>

Assuming a suitable grammar, it's quite easy to write a handcrafted
recursive descent parser. I've done it a number of times over the years.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.