Can a compiler work without an Operating System?

[Vansh Kapoor]

I was reading this book 'Computer Systems' and it made me wander if the compiler exists in Operating system or it can individualy work with the processor main memory and I/O bridges.

[John Levine]

Post by Vansh Kapoor
I was reading this book 'Computer Systems' and it made me wander if the compiler exists in Operating system or it can individualy work with the processor main memory
and I/O bridges.

It's less common now but there have been plenty of compilers that
worked without operating systems. The original FORTRAN compiler ran on
an IBM 704, loaded directly from mag tape. When I was using a PDP-8
around 1970 it didn't have an operating system but there were
assemblers and a Fortran compiler we loaded from paper tape.

[Bob Eager]

Post by Vansh Kapoor
I was reading this book 'Computer Systems' and it made me wander if the
compiler exists in Operating system or it can individualy work with the
processor main memory and I/O bridges.

It's less common now but there have been plenty of compilers that worked
without operating systems. The original FORTRAN compiler ran on an IBM
704, loaded directly from mag tape. When I was using a PDP-8 around 1970
it didn't have an operating system but there were assemblers and a
Fortran compiler we loaded from paper tape.

And, indeed, that can apply to any program.

[Thomas Koenig]

Post by John Levine

Post by Vansh Kapoor
I was reading this book 'Computer Systems' and it made me wander if the compiler exists in Operating system or it can individualy work with the processor main memory
and I/O bridges.

It's less common now but there have been plenty of compilers that
worked without operating systems. The original FORTRAN compiler ran on
an IBM 704, loaded directly from mag tape. When I was using a PDP-8
around 1970 it didn't have an operating system but there were
assemblers and a Fortran compiler we loaded from paper tape.

It can also be argued that MS-DOS or CP/M are not operating systems, but rather
a program loader and a collection of auxiliary routines, so a compilers
for these systems might also serve as examples.

[Ahem A Rivet's Shot]

On Mon, 26 Feb 2024 17:52:26 -0000 (UTC)

Post by Thomas Koenig
It can also be argued that MS-DOS or CP/M are not operating systems, but
rather a program loader and a collection of auxiliary routines, so a
compilers for these systems might also serve as examples.

The counter argument is that both include user interfaces and file
systems. But yeah they're borderline.

[Niklas Karlsson]

Post by Ahem A Rivet's Shot
On Mon, 26 Feb 2024 17:52:26 -0000 (UTC)

Post by Thomas Koenig
It can also be argued that MS-DOS or CP/M are not operating systems, but
rather a program loader and a collection of auxiliary routines, so a
compilers for these systems might also serve as examples.

The counter argument is that both include user interfaces and file
systems. But yeah they're borderline.

Maybe you could call them (glorified) bootloaders? Those often have user
interfaces and at least rudimentary file system support.

Niklas

[Kerr-Mudd, John]

On 26 Feb 2024 18:35:37 GMT

Post by Niklas Karlsson

Post by Ahem A Rivet's Shot
On Mon, 26 Feb 2024 17:52:26 -0000 (UTC)

Post by Thomas Koenig
It can also be argued that MS-DOS or CP/M are not operating systems, but
rather a program loader and a collection of auxiliary routines, so a
compilers for these systems might also serve as examples.

The counter argument is that both include user interfaces and file
systems. But yeah they're borderline.

Maybe you could call them (glorified) bootloaders? Those often have user
interfaces and at least rudimentary file system support.

I don't like such grubby talk.

[Scott Lurndal]

Post by Kerr-Mudd, John
On 26 Feb 2024 18:35:37 GMT

Post by Niklas Karlsson

Post by Ahem A Rivet's Shot
On Mon, 26 Feb 2024 17:52:26 -0000 (UTC)

Post by Thomas Koenig
It can also be argued that MS-DOS or CP/M are not operating systems, but
rather a program loader and a collection of auxiliary routines, so a
compilers for these systems might also serve as examples.

The counter argument is that both include user interfaces and file
systems. But yeah they're borderline.

Maybe you could call them (glorified) bootloaders? Those often have user
interfaces and at least rudimentary file system support.

I don't like such grubby talk.

li lo, li lo, it's off to work we go?

[Carlos E.R.]

Post by Thomas Koenig

Post by John Levine

Post by Vansh Kapoor
I was reading this book 'Computer Systems' and it made me wander if the compiler exists in Operating system or it can individualy work with the processor main memory
and I/O bridges.

It's less common now but there have been plenty of compilers that
worked without operating systems. The original FORTRAN compiler ran on
an IBM 704, loaded directly from mag tape. When I was using a PDP-8
around 1970 it didn't have an operating system but there were
assemblers and a Fortran compiler we loaded from paper tape.

It can also be argued that MS-DOS or CP/M are not operating systems, but rather
a program loader and a collection of auxiliary routines, so a compilers
for these systems might also serve as examples.

I do not agree.

They are simply primitive oses.

[John Dallman]

Post by Carlos E.R.

Post by Thomas Koenig
It can also be argued that MS-DOS or CP/M are not operating
systems, but rather a program loader and a collection of
auxiliary routines, so compilers for these systems might
also serve as examples.

I do not agree.
They are simply primitive oses.

Agreed. Compilers running on MS-DOS and CP/M were, in general, some of
the best-behaved software for those systems. They took pains to operate
via system facilities, and not access hardware directly. This was mostly
because they didn't need direct hardware access, and avoiding it made
them more portable.

John

[Ahem A Rivet's Shot]

On Tue, 27 Feb 2024 08:39 +0000 (GMT Standard Time)

Post by John Dallman
Agreed. Compilers running on MS-DOS and CP/M were, in general, some of
the best-behaved software for those systems.

Hmm then there was the CP/M BCPL compiler that depended on running
on a Z80 based CP/M machine because it used the alternate register set to
avoid pushing registers onto the stack - after all CP/M is an 8080 based OS
so nothing should be using them - right?

Then there was the Micromation development system with a bunch of
Z80 boards running CP/M with one running MP/M that took care of job
dispatching when something was put in the background. If it ran out of Z80s
running CP/M it ran tasks itself under MP/M. What a pity that the task
dispatcher written specially for this Z80 based system used the alternate
register set to avoid pushing registers on the stack - after all CP/M is an
8080 based OS so nothing should be using the - right.

We stopped putting BCPL compiles into the background once we worked
out what was crashing the system when we got busy.

[Carlos E.R.]

Post by Ahem A Rivet's Shot
On Tue, 27 Feb 2024 08:39 +0000 (GMT Standard Time)

Post by John Dallman
Agreed. Compilers running on MS-DOS and CP/M were, in general, some of
the best-behaved software for those systems.

Hmm then there was the CP/M BCPL compiler that depended on running
on a Z80 based CP/M machine because it used the alternate register set to
avoid pushing registers onto the stack - after all CP/M is an 8080 based OS
so nothing should be using them - right?
Then there was the Micromation development system with a bunch of
Z80 boards running CP/M with one running MP/M that took care of job
dispatching when something was put in the background. If it ran out of Z80s
running CP/M it ran tasks itself under MP/M. What a pity that the task
dispatcher written specially for this Z80 based system used the alternate
register set to avoid pushing registers on the stack - after all CP/M is an
8080 based OS so nothing should be using the - right.
We stopped putting BCPL compiles into the background once we worked
out what was crashing the system when we got busy.

Yes, on those systems you could do optimizations based on the particular
hardware available. The most usual was writing to the display memory
directly, for speed. Even for plain text.

Well, today you can do computing using the graphic cards, and that's
probably non generic.

[Peter Flass]

Post by Carlos E.R.

Post by Thomas Koenig

Post by John Levine

Post by Vansh Kapoor
I was reading this book 'Computer Systems' and it made me wander if
the compiler exists in Operating system or it can individualy work
with the processor main memory
and I/O bridges.

It's less common now but there have been plenty of compilers that
worked without operating systems. The original FORTRAN compiler ran on
an IBM 704, loaded directly from mag tape. When I was using a PDP-8
around 1970 it didn't have an operating system but there were
assemblers and a Fortran compiler we loaded from paper tape.

It can also be argued that MS-DOS or CP/M are not operating systems, but rather
a program loader and a collection of auxiliary routines, so a compilers
for these systems might also serve as examples.

I do not agree.
They are simply primitive oses.

Back in the old days they might be considered “resident monitors” + IOCS

[Ahem A Rivet's Shot]

On Mon, 19 Feb 2024 17:40:41 -0800 (PST)

Post by Vansh Kapoor
I was reading this book 'Computer Systems' and it made me wander if the
compiler exists in Operating system or it can individualy work with the
processor main memory and I/O bridges.

Most certainly, although it is far from common these days. The most
recent example I know of isn't exactly a compiler but it's close[1].
Smalltalk V/286 started running under MSDOS but promptly switched to
protected mode and abandoned the OS it had used only as a launcher.

[1] OK it was more like a seething mass of mutable objects with an embedded
compiler.

[Carlos E.R.]

Post by Ahem A Rivet's Shot
On Mon, 19 Feb 2024 17:40:41 -0800 (PST)

Post by Vansh Kapoor
I was reading this book 'Computer Systems' and it made me wander if the
compiler exists in Operating system or it can individualy work with the
processor main memory and I/O bridges.

Most certainly, although it is far from common these days. The most
recent example I know of isn't exactly a compiler but it's close[1].
Smalltalk V/286 started running under MSDOS but promptly switched to
protected mode and abandoned the OS it had used only as a launcher.
[1] OK it was more like a seething mass of mutable objects with an embedded
compiler.

I can not see the OP (because it comes from Google groups) but it is
common with small machines to not have an operating system.

This thing, for instance:

https://www.shelly.com/en


From second hand information, you compile adding the parts you are
going to use, as space is limited.

[Andy Burns]

it is common with small machines to not have an operating system.
https://www.shelly.com/en

I doubt that a 'smart' switch provides a compiler ...

[Ahem A Rivet's Shot]

On Wed, 21 Feb 2024 19:50:08 +0000

Post by Andy Burns

it is common with small machines to not have an operating system.
https://www.shelly.com/en

I doubt that a 'smart' switch provides a compiler ...

Find out what chip/SOC it uses and look for the manufacturer's SDK.

[Carlos E.R.]

Post by Andy Burns

it is common with small machines to not have an operating system.
https://www.shelly.com/en

I doubt that a 'smart' switch provides a compiler ...

No, you do it externally. Write the code, compile, link with the runtime
library, and flash it to the module. I haven't done it personally, so I
do not know more.

[Carlos E.R.]

Post by Carlos E.R.

Post by Andy Burns

it is common with small machines to not have an operating system.
https://www.shelly.com/en

I doubt that a 'smart' switch provides a compiler ...

No, you do it externally. Write the code, compile, link with the runtime
library, and flash it to the module. I haven't done it personally, so I
do not know more.

I realize now that you understand the question about running the
compiler without an OS, while I understood running the resulting program.

Well, I have not experienced compilers without an OS, but indeed an
interpreter without an OS. The Sinclair ZX81 or the Spectrum, had an
interpreter without an OS. Basic. The program would be saved to tape,
but there were no "files".

Even the original IBM PC could run Basic in ROM without an OS (and tape
recorder), but the BIOS in ROM was available to it.


Wikipedia mentions several compiled languages for the Spectrum:


<https://en.wikipedia.org/wiki/ZX_Spectrum_software#Other_software>

Programming language implementations

C[26]
Pascal[27]
Prolog[28]
Forth[29]
Z80 assemblers/disassemblers:
OCP Editor/Assembler
HiSoft Devpac
ZEUS Assembler
Artic Assembler
Sinclair BASIC extensions and compilers:
Beta BASIC
Mega Basic
MCoder
COLT
HiSoft BASIC
ToBoS-FP



So the answer to the OP question is "yes".

[Bob Martin]

Post by Andy Burns

it is common with small machines to not have an operating system.
https://www.shelly.com/en

I doubt that a 'smart' switch provides a compiler ...

Many of the early IBM 360 programs were loaded from card decks.
I remember using DEBE a lot.
OS/360 version was 4/5 when I started (never used DOS or TOS).

[John Levine]

Post by Bob Martin
Many of the early IBM 360 programs were loaded from card decks.
I remember using DEBE a lot.

For very small 360s or I suppose for low level program developmen, IBM
had Basic Programming Support (BPS) all of which loaded from cards. It
had RPG, an assembler, loaders, I/O library, and some I/O utilities to
copy stuff and format disks.

https://bitsavers.org/pdf/ibm/360/bos_bps/

[Charlie Gibbs]

Post by John Levine

Post by Bob Martin
Many of the early IBM 360 programs were loaded from card decks.
I remember using DEBE a lot.

For very small 360s or I suppose for low level program developmen, IBM
had Basic Programming Support (BPS) all of which loaded from cards. It
had RPG, an assembler, loaders, I/O library, and some I/O utilities to
copy stuff and format disks.
https://bitsavers.org/pdf/ibm/360/bos_bps/

My first job was on a Univac 9300 (their answer to the 360/20).
We eventually added disks to it, but originally it was a card-based
system that had no operating system. Programs were loaded from
card decks; one of the things the linker did was to punch a boot
loader in front of the program image(s) that we had created with
the assembler. RPG was a huge self-loading card deck into which
you interspersed the various parts of your source code; by the
time this deck got all the way through the reader, it had punched
the binary of your program, complete with boot loader. (I was
able to recognize when someone was doing an RPG compile from
the next room by the rhythm of the printer, and could even tell
whether it compiled cleanly or had errors.)

[Lynn Wheeler]

Post by John Levine
For very small 360s or I suppose for low level program developmen, IBM
had Basic Programming Support (BPS) all of which loaded from cards. It
had RPG, an assembler, loaders, I/O library, and some I/O utilities to
copy stuff and format disks.
https://bitsavers.org/pdf/ibm/360/bos_bps/

I took two credit hr intro to fortran/computers. Univ had 709/1401 and
IBM pitched 360/67 for tss/360 as replacement. Pending availability of
360/67, the 1401 was replaced with 64k 360/30 (that had 1401 emulation)
to start getting 360 experience. At the end of the intro clss, I was
hired to rewrite 1401 MPIO (card reader->tape, tape->printer/punch, aka
unit record front end for 709 running tape->tape) for 360/30, part of
getting 360 experience. The univ shutdown datacenter over the weekend
and I got the whole place dedicated (but 48hrs w/o sleep made monday
classes hard). They gave me a bunch of hardware and software manuals and
I got to design and implement my own monitor, device drivers, interrupt
handlers, storage management, error recovery, etc and within a few weeks
had 2000 card program that ran stand-alone (IPL'ed with the BPS
loader).

I then modified it with assembler option that generated either the stand
alone version (took 30mins to assemble) or OS/360 with system services
macros (took 60mins to assemble, each DCB macro taking 5-6mins). I
quickly learned 1st thing coming in sat. morning was clean the tape
drives and printers, disassemble the 2540 printer/punch, clean it and
reassemble. Also sometimes sat. morning, production had finished early
and everything was powered off. Sometimes 360/30 wouldn't power on and
reading manuals and trail&error would place all the controllers in CE
mode, power-on the 360/30, individually power-on each controller, then
placing them back in normal mode.

Within a year of the intro class, the 360/67 arrived and I was hired
fulltime responsible for os/360 (TSS/360 never came to production so ran
as 360/65). Then some people from science center came out to install
CP67 (precursor to vm370) ... 3rd after CSC itself and MIT Lincoln labs;
and I mostly played with it in my 48hr weekend window. Initially cp67
kernel was couple dozen assembler source routines originally kept on
os/360 ... individually assembled and txt output placed in card tray in
correct order behind BPS loader to IPL kernel... which writes memory
image to disk. disk then can be IPLed to run CP67. Each module TXT deck
had diagonal stripe and module name across top ... so updating and
replacing individual module (in card tray) can be easily
identify/done. Later CP67 source was moved to CMS and it was possible to
assemble and then virtually punch BPS loader and TXT output that is
transferred to an input reader, (virtually) IPL it and have it written
to disk (potentially even the production system disk) for re-ipl.

One of the things I worked on was a mechanism for paging part of the
CP67 kernel (reducing fixed storage requirement) ... reworking some code
into 4kbyte segments ... which increased the number of ESD entry symbols
... and eventually found I started running into the BPS loader 255 ESD
limit.

[Peter Flass]

Post by Lynn Wheeler

Post by John Levine
For very small 360s or I suppose for low level program developmen, IBM
had Basic Programming Support (BPS) all of which loaded from cards. It
had RPG, an assembler, loaders, I/O library, and some I/O utilities to
copy stuff and format disks.
https://bitsavers.org/pdf/ibm/360/bos_bps/

I took two credit hr intro to fortran/computers. Univ had 709/1401 and
IBM pitched 360/67 for tss/360 as replacement. Pending availability of
360/67, the 1401 was replaced with 64k 360/30 (that had 1401 emulation)
to start getting 360 experience. At the end of the intro clss, I was
hired to rewrite 1401 MPIO (card reader->tape, tape->printer/punch, aka
unit record front end for 709 running tape->tape) for 360/30, part of
getting 360 experience. The univ shutdown datacenter over the weekend
and I got the whole place dedicated (but 48hrs w/o sleep made monday
classes hard). They gave me a bunch of hardware and software manuals and
I got to design and implement my own monitor, device drivers, interrupt
handlers, storage management, error recovery, etc and within a few weeks
had 2000 card program that ran stand-alone (IPL'ed with the BPS
loader).
I then modified it with assembler option that generated either the stand
alone version (took 30mins to assemble) or OS/360 with system services
macros (took 60mins to assemble, each DCB macro taking 5-6mins).

One hack I thought of long past the time it would have been useful would be
to stick all the DCBs (and maybe etc.). into a separate module, assemble it
once, and then just link the object deck with the rest of the code.

[Theo]

Post by Vansh Kapoor
I was reading this book 'Computer Systems'

Is it interesting? Who are the authors?

Post by Vansh Kapoor
and it made me wander if the compiler exists in Operating system or it
can individualy work with the processor main memory and I/O bridges.

It's not clear if you mean running the compiler without an operating
system of if the compiler is able to produce a program that can run
without an operating system. I think you mean the former---can the
compiler bootstrap the computer system and offer an interface to the
user to write programs, compile and run them? This would make the
compiler also be a text editor and a shell, essentially replacing the
entire operating system. That's not what typical compilers are.

It really depends on the nature of your I/O. A compiler transforms source
code into object code (or machine code). With a modern compiler the source
and machine code are stored in files so you need something to provide a file
abstraction, which we call an OS. But I could imagine where you fed in
first the compiler binary on paper tape, then your source code on another
tape. This prints a tape holding the machine code output. Then you feed
that tape back into the machine to run it.

If you could do a modern reimagination of that idea you could have it work
without an OS. But it's hard to see why you would want to.

You could also implement file handling inside the compiler, so the compiler
talks to the storage directly to fetch files, and has the ability to load
and execute compiled code itself. But that's really just embedding OS
functions inside the compiler.

Theo

[Stefan Ram]

Post by Theo
It really depends on the nature of your I/O.

In a /freestanding environment/, C program execution may take place
without the benefit of an operating system; the name and type of the
function called at program startup, the library facilities available,
and the effect of program termination are all implementation-defined.

To learn more about C and freestanding environments, have a look at
ISO/IEC 9899:2023 (E)!

[songbird]

Post by Vansh Kapoor
I was reading this book 'Computer Systems' and it made me wander if the compiler exists in Operating system or it can individualy work with the processor main memory and I/O bridges.

there's nothing preventing the OS from being some
kind of language interpreter or compiler, but i would
think that would be a very embedded type of system
these days.

one of the benefits of more recent ideas is that it
really helps to keep different functions isolated a
bit from each other so they can be tested and not
have the rest of the system so tightly coupled.

how would you upgrade such a monolithic system?
what would there be for quality control or testing?
etc.


songbird