• Please review our updated Terms and Rules here

1983 - coming ready or not

kerravon

Experienced Member
Joined
Oct 31, 2021
Messages
136
I have previously posted about trying to reach back
to 1990. Since then I have transitioned to 1986 (when
the first 80386 computer had a 40 MB hard disk) and
today I have moved back to 1983 when the IBM PC XT
came out. Although I'm using a 20 MB hard disk instead
of the standard 10 MB.

See http://pdos.org for University Challenge 8086.

It comes with a C compiler that is close to C90, and
builds MSDOS executables.

It is unclear what the system is capable of.

Every byte of the disk is public domain.

BFN. Paul.
 
Let us know when you get to 1959. :)

I don't think I can go back beyond the 8086.

The OS alone is about 64k, and the C compiler
alone is about 64k. Plus working memory is
required.

And I wish to write these things in C rather than
assembler.

And I don't want to have to have kludges like
transient areas/overlays.

Basically if I could go back in time, I'd take my C
code, then wait for the 16:16 processor to come
along and then wait until I could afford the memory
required.

I guess while I'm waiting for that I could dabble in
some assembler code.

BFN. Paul.
 
Since C and Unix were both developed on the 16 bit PDP-11, you could go back to 1970, when the PDP-11/20 was introduced.

Hmm... looks like you can get the V1 Unix kernel running the V2 userland (1972) to run on an emulated PDP-11/20 in SIMH, so maybe a 1972 tool chain would be the earliest usable to build your OS for the PDP-11:


Though it seems that V6 Unix from 1975 is probably the oldest with a full tool chain / doc set, on an emulated 11/45. Or maybe on RSX-11?

Looks like the 11/20 could only address 16 bit memory, for 32 kwords (64 kbytes). The 11/45 introduced in 1972 was the first with 18 bit physical memory addressing, so it could handle 128 kwords (256 kbytes).
 
Since C and Unix were both developed on the 16 bit PDP-11, you could go back to 1970, when the PDP-11/20 was introduced.

If it is possible to code in 64k, I don't necessarily need the PDP-11 - I could use the 8080 or 6502.

I'm just wondering how that is technically possible. Adding typedef to SubC broke the DOS small memory model.

Nils said:

BTW, typedefs breaks the DOS port, because the
compiler is now too big to fit in a 64KB text
segment.

I guess it would be possible to save space by running the compiler stages as separate executables.

But I guess that's what I don't want to do. I want an unkludged executable. ie for
the code to look nice.

I'm happy to splurge on 640k of memory to make that happen.

My actual goal is ill-defined. What would a sensible goal be?

I think I want a neat programming solution to the problem,
and only later start kludging the code to cater for real-world
limitations.

BFN. Paul.
 
Multipass, separate processes were common back in the day, for all compilers on the 8080 through 80286, and started to phase out after that. Turbo Pascal was the (partial) exception. It mostly ran completely in memory, although I recall some tools were separate executables for something I don't remember. Even in Unix, you used to build compilers using Lex and YACC. Even some of the assemblers were multiple processes. When you have less than 64k to do your work, you get creative...
 
Turbo Pascal was a single pass compiler out of necessity since the Blue Label Pascal was written for a Nascom computer using cassettes. Multipass compiling would require the user to rewind the tape. Turbo Pascal ran fine off cassette as the copyright ignoring Soviet ISPP compiler.
 
Wasn't there a C for the PDP 10 (36 bit words)? There was certainly one for the CDC 6000 series (60 bit words, ones complement math; addressing granularity is word). Standard memory was 128Kib words. That would take you back to 1964.
 
The challenge should be a bit more modest to something that could be done in a few part time months at most. Looking at 1983 academic OSes, the result would have long file names, a very slow and cumbersome file system, and virtually no compatibility with anything else.
 
The challenge should be a bit more modest to something that could be done in a few part time months at most. Looking at 1983 academic OSes, the result would have long file names, a very slow and cumbersome file system, and virtually no compatibility with anything else.
Could you elaborate on "the challenge"? Who do you think should be doing this? For what purpose? And should they have been doing this back in 1983 or in 2022? If 2022, then which processor?
 
Could you elaborate on "the challenge"? Who do you think should be doing this? For what purpose? And should they have been doing this back in 1983 or in 2022? If 2022, then which processor?
Your challenge is to produce a better 16-bit competitor to MSDOS using just what is on this disk.
I don't expect a university in 1983 to put in effort making a low end practical OS. Making even a minimal OS is a considerable amount of work, more than just for a fun summer break.

I am not sure what sort of project would make sense to add to the PDOS skeleton and can be accomplished in a reasonable amount of time. If a project is going to take many years to produce results, it had better be a paid consulting gig.
 
I don't expect a university in 1983 to put in effort making a low end practical OS. Making even a minimal OS is a considerable amount of work, more than just for a fun summer break.

I am not sure what sort of project would make sense to add to the PDOS skeleton and can be accomplished in a reasonable amount of time. If a project is going to take many years to produce results, it had better be a paid consulting gig.
Perhaps PDOS/86 could be replaced by a sequence of fun summer breaks over a period of years, by different people? Assuming there is a sound design upfront.
 
If you look for inspiration, you could look at the DeSmet C source code. I think it's wonderful as from version 3.1 is an ANSI C compatible compiler, and it even has an assembler. The executables for the compiler/tools/assembler are incredibly tiny, in comparison with other compilers/assemblers of the late 80s like Microsoft's and Borland's. Everything is, curiously, coded in C language (except for a few assembler modules and a few inlined assembly instructions).

For me, it's a very curiose case of what was before, the chicken, or the egg? What was the compiler used for the very first version? The current maintainer of both the site and the code (he's not the original developer) doesn't have the answer... Paradoxically, you can use DeSmet C to compile DeSmet...
 
Everything is, curiously, coded in C language (except for a few assembler modules and a few inlined assembly instructions).

For me, it's a very curiose case of what was before, the chicken, or the egg? What was the compiler used for the very first version? The current maintainer of both the site and the code (he's not the original developer) doesn't have the answer... Paradoxically, you can use DeSmet C to compile DeSmet...
Self-hosting compilers aren't that unusual. Typically I guess you'd start developing the compiler in another language, say assembly, and once you have the capability to compile at least some C code, you can start replacing bits of the source with your version of C until you've got something that can compile itself.
 
Self-hosting compilers aren't that unusual. Typically I guess you'd start developing the compiler in another language, say assembly, and once you have the capability to compile at least some C code, you can start replacing bits of the source with your version of C until you've got something that can compile itself.
I doubt that anyone starts with assembler. You can instead just use someone else's C compiler, even if it runs on a different processor.

The very first C compiler would need to be (and was) written in a different language though, but not assembler.

I guess if we were restarting the entire software industry from scratch, with a goal of having a C compiler, we would write it in assembler for an arbitrary processor. I can't think of a way around that.
 
If you look for inspiration, you could look at the DeSmet C source code. I think it's wonderful as from version 3.1 is an ANSI C compatible compiler, and it even has an assembler.
Note that PDOS/86 ships with SubC, which is a pretty large subset of C90, and public domain. DeSmet is copyrighted. SubC includes an assembler/archiver/linker, also public domain.
 
I doubt that anyone starts with assembler. You can instead just use someone else's C compiler, even if it runs on a different processor.

The very first C compiler would need to be (and was) written in a different language though, but not assembler.
It all depends on the era, the company and the type of product. For example, the modus operandi of Microsoft, during the first half of the 1980s, was using assembler for (almost) everything. Take for example the source code of GwBasic and the above mentioned MS-DOS. Circa 1985 onwards, they started to gradually adopt C as the main programming language.
 
It all depends on the era, the company and the type of product. For example, the modus operandi of Microsoft, during the first half of the 1980s, was using assembler for (almost) everything. Take for example the source code of GwBasic and the above mentioned MS-DOS. Circa 1985 onwards, they started to gradually adopt C as the main programming language.
Yes, my impression is that it really does depend. It's not that you *must* start with assembly language, but I don't see why the idea is so questionable.

And whatever Microsoft did in the 1980s, it's saner than the way they developed Altair BASIC through BASIC-86 on emulators of Intel CPUs, which they wrote and ran on DEC minicomputers before they ever had access to the real silicon...
 
Back
Top