[TUHS] Re: History of non-Bell C compilers?

[TUHS] Re: History of non-Bell C compilers?

[Paul Ruizendaal]

On Thu, Mar 7, 2024, 4:14 PM Tom Lyon <pugs78 at gmail.com> wrote:

> For no good reason, I've been wondering about the early history of C
> compilers that were not derived from Ritchie, Johnson, and Snyder at Bell.
> Especially for x86.  Anyone have tales?
> Were any of those compilers ever used to port UNIX?

An unusual one would be the “revenue bomb” compiler that Charles Simonyi and Richard Brodie did at Microsoft in 1981.

This compiler was intended to provided a uniform environment for the menagerie of 8 and 16-bit computers of the era. It compiled to a byte code which executed through a small interpreter. This by itself was hardly new of course, but it had some unique features. It generated code in overlays, so that it could run a code base larger than 64KB (but it defined only one data segment). It also defined a small set of “system” commands, that allowed for uniform I/O. I still have the implementation spec for that interpreter somewhere.

This compiler was used for the first versions of Multiplan and Word, and my understanding is that the byte code engine was later re-used in Visual Basic. I think the compiler also had a Xenix port, maybe it even was Xenix native (and at this time, Xenix would still essentially have been V7).

I am not sure to what extent this compiler was independent of the Bell compilers. It could well be that it was based on PCC, Microsoft was a Unix licensee after all and at the time busy doing ports. On the other hand, Charles Simonyi would certainly have been capable of creating his own from scratch. I do know that this compiler preceded Lattice C, the latter of which was distributed by Microsoft as Microsoft C 1.0.

Maybe others know more about this Simonyi/Brodie compiler?

Paul

Notes:
http://www.memecentral.com/mylife.htm
https://web.archive.org/web/20080905231519/http://www.computerworld.com/softwaretopics/software/appdev/story/0%2C10801%2C76413%2C00.html
http://seefigure1.com/images/xenix/xenix-timeline.jpg

[TUHS] Re: History of non-Bell C compilers?

[Marc Rochkind]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

Since it came up in this thread, here's my review of Coherent in BYTE
Magazine (1985):

https://www.mrochkind.com/mrochkind/docs/Byte-Pick-Coherent-Theos.pdf

Marc

On Mon, Mar 11, 2024 at 11:13 AM Paul Ruizendaal <pnr@planet.nl> wrote:

> On Thu, Mar 7, 2024, 4:14 PM Tom Lyon <pugs78 at gmail.com> wrote:
>
> > For no good reason, I've been wondering about the early history of C
> > compilers that were not derived from Ritchie, Johnson, and Snyder at
> Bell.
> > Especially for x86.  Anyone have tales?
> > Were any of those compilers ever used to port UNIX?
>
> An unusual one would be the “revenue bomb” compiler that Charles Simonyi
> and Richard Brodie did at Microsoft in 1981.
>
> This compiler was intended to provided a uniform environment for the
> menagerie of 8 and 16-bit computers of the era. It compiled to a byte code
> which executed through a small interpreter. This by itself was hardly new
> of course, but it had some unique features. It generated code in overlays,
> so that it could run a code base larger than 64KB (but it defined only one
> data segment). It also defined a small set of “system” commands, that
> allowed for uniform I/O. I still have the implementation spec for that
> interpreter somewhere.
>
> This compiler was used for the first versions of Multiplan and Word, and
> my understanding is that the byte code engine was later re-used in Visual
> Basic. I think the compiler also had a Xenix port, maybe it even was Xenix
> native (and at this time, Xenix would still essentially have been V7).
>
> I am not sure to what extent this compiler was independent of the Bell
> compilers. It could well be that it was based on PCC, Microsoft was a Unix
> licensee after all and at the time busy doing ports. On the other hand,
> Charles Simonyi would certainly have been capable of creating his own from
> scratch. I do know that this compiler preceded Lattice C, the latter of
> which was distributed by Microsoft as Microsoft C 1.0.
>
> Maybe others know more about this Simonyi/Brodie compiler?
>
> Paul
>
> Notes:
> http://www.memecentral.com/mylife.htm
>
> https://web.archive.org/web/20080905231519/http://www.computerworld.com/softwaretopics/software/appdev/story/0%2C10801%2C76413%2C00.html
> http://seefigure1.com/images/xenix/xenix-timeline.jpg



-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

[-- Attachment #2: Type: text/html, Size: 3477 bytes --]

[TUHS] Re: History of non-Bell C compilers?

[Peter Yardley]

I used the DEC VMS C compiler extensively while I was at NSWIT. I ported a lot of Berkley (I think) C code to VMS. Some of their VLSI design suite, KIC etc. There weren’t a lot of changes to make, the compiler and library was pretty K&R from what I remember. The usual small header issues applied. VMS IO is a bit different from UNIX IO  but they had a mode (stream I think) that meant minimal changes to UNIX code.

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/lang/c/AI-L370C-TE_Guide_to_VAX_C_V2.3_Mar1987.pdf

It did help that the code I was working with was pretty damn good. I learn C porting KIC to VMS.

> On 12 Mar 2024, at 7:44 AM, Marc Rochkind <mrochkind@gmail.com> wrote:
> 
> Since it came up in this thread, here's my review of Coherent in BYTE Magazine (1985):
> 
> https://www.mrochkind.com/mrochkind/docs/Byte-Pick-Coherent-Theos.pdf
> 
> Marc
> 
> On Mon, Mar 11, 2024 at 11:13 AM Paul Ruizendaal <pnr@planet.nl> wrote:
> On Thu, Mar 7, 2024, 4:14 PM Tom Lyon <pugs78 at gmail.com> wrote:
> 
> > For no good reason, I've been wondering about the early history of C
> > compilers that were not derived from Ritchie, Johnson, and Snyder at Bell.
> > Especially for x86.  Anyone have tales?
> > Were any of those compilers ever used to port UNIX?
> 
> An unusual one would be the “revenue bomb” compiler that Charles Simonyi and Richard Brodie did at Microsoft in 1981.
> 
> This compiler was intended to provided a uniform environment for the menagerie of 8 and 16-bit computers of the era. It compiled to a byte code which executed through a small interpreter. This by itself was hardly new of course, but it had some unique features. It generated code in overlays, so that it could run a code base larger than 64KB (but it defined only one data segment). It also defined a small set of “system” commands, that allowed for uniform I/O. I still have the implementation spec for that interpreter somewhere.
> 
> This compiler was used for the first versions of Multiplan and Word, and my understanding is that the byte code engine was later re-used in Visual Basic. I think the compiler also had a Xenix port, maybe it even was Xenix native (and at this time, Xenix would still essentially have been V7).
> 
> I am not sure to what extent this compiler was independent of the Bell compilers. It could well be that it was based on PCC, Microsoft was a Unix licensee after all and at the time busy doing ports. On the other hand, Charles Simonyi would certainly have been capable of creating his own from scratch. I do know that this compiler preceded Lattice C, the latter of which was distributed by Microsoft as Microsoft C 1.0.
> 
> Maybe others know more about this Simonyi/Brodie compiler?
> 
> Paul
> 
> Notes:
> http://www.memecentral.com/mylife.htm
> https://web.archive.org/web/20080905231519/http://www.computerworld.com/softwaretopics/software/appdev/story/0%2C10801%2C76413%2C00.html
> http://seefigure1.com/images/xenix/xenix-timeline.jpg
> 
> 
> -- 
> My new email address is mrochkind@gmail.com

Peter Yardley
peter.martin.yardley@gmail.com

[TUHS] Re: History of non-Bell C compilers?

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 4891 bytes --]

One of the neatest compilers I worked with was Eric Biederman's romcc.

"romcc is a C compiler which produces binaries which do not rely on RAM, but
instead only use CPU registers."

We used romcc for 15 years or so. It was critical to getting DRAM and
Hypertransport topology working on the Opteron. Remember: at
power-on/reset, RAM is dead, dead, dead, and getting it going on newer
systems is (literally) billions of instructions. So, no ram. The only "ram"
romcc had were the general purpose registers. Later, eric added support for
the SIMD registers, and "memory" grew a few hundred bytes. No memory, no
stack: 100% inlining. romcc knew how to use puddle arithmetic and all the
other tricks. It was amazing.

It is a full ANSI C compiler (as of 2006 ANSI C) in 25KLOC code, in one
file: https://github.com/wt/coreboot/blob/master/util/romcc/romcc.c

The story of its creation, as told to me by the Linux NetworX CTO ca 2004:
Eric worked at Linux NetworX at the time, and they were shipping
LinuxBIOS-based systems. Everyone working with Opteron was suffering with
assembly. Eric vanished for 30 days, and on the 31st day returned from the
mountain (or his apartment I guess) with romcc, and It Was Good. Really
good. The code we wrote for Opteron Hypertransport was far better than
AMDs; they even admitted it to us later.  We could even run with empty
Socket 0; they could not.

Last I checked, it still builds and 100 or so regression tests work just
fine.



On Mon, Mar 11, 2024 at 3:28 PM Peter Yardley <
peter.martin.yardley@gmail.com> wrote:

> I used the DEC VMS C compiler extensively while I was at NSWIT. I ported a
> lot of Berkley (I think) C code to VMS. Some of their VLSI design suite,
> KIC etc. There weren’t a lot of changes to make, the compiler and library
> was pretty K&R from what I remember. The usual small header issues applied.
> VMS IO is a bit different from UNIX IO  but they had a mode (stream I
> think) that meant minimal changes to UNIX code.
>
>
> http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/lang/c/AI-L370C-TE_Guide_to_VAX_C_V2.3_Mar1987.pdf
>
> It did help that the code I was working with was pretty damn good. I learn
> C porting KIC to VMS.
>
> > On 12 Mar 2024, at 7:44 AM, Marc Rochkind <mrochkind@gmail.com> wrote:
> >
> > Since it came up in this thread, here's my review of Coherent in BYTE
> Magazine (1985):
> >
> > https://www.mrochkind.com/mrochkind/docs/Byte-Pick-Coherent-Theos.pdf
> >
> > Marc
> >
> > On Mon, Mar 11, 2024 at 11:13 AM Paul Ruizendaal <pnr@planet.nl> wrote:
> > On Thu, Mar 7, 2024, 4:14 PM Tom Lyon <pugs78 at gmail.com> wrote:
> >
> > > For no good reason, I've been wondering about the early history of C
> > > compilers that were not derived from Ritchie, Johnson, and Snyder at
> Bell.
> > > Especially for x86.  Anyone have tales?
> > > Were any of those compilers ever used to port UNIX?
> >
> > An unusual one would be the “revenue bomb” compiler that Charles Simonyi
> and Richard Brodie did at Microsoft in 1981.
> >
> > This compiler was intended to provided a uniform environment for the
> menagerie of 8 and 16-bit computers of the era. It compiled to a byte code
> which executed through a small interpreter. This by itself was hardly new
> of course, but it had some unique features. It generated code in overlays,
> so that it could run a code base larger than 64KB (but it defined only one
> data segment). It also defined a small set of “system” commands, that
> allowed for uniform I/O. I still have the implementation spec for that
> interpreter somewhere.
> >
> > This compiler was used for the first versions of Multiplan and Word, and
> my understanding is that the byte code engine was later re-used in Visual
> Basic. I think the compiler also had a Xenix port, maybe it even was Xenix
> native (and at this time, Xenix would still essentially have been V7).
> >
> > I am not sure to what extent this compiler was independent of the Bell
> compilers. It could well be that it was based on PCC, Microsoft was a Unix
> licensee after all and at the time busy doing ports. On the other hand,
> Charles Simonyi would certainly have been capable of creating his own from
> scratch. I do know that this compiler preceded Lattice C, the latter of
> which was distributed by Microsoft as Microsoft C 1.0.
> >
> > Maybe others know more about this Simonyi/Brodie compiler?
> >
> > Paul
> >
> > Notes:
> > http://www.memecentral.com/mylife.htm
> >
> https://web.archive.org/web/20080905231519/http://www.computerworld.com/softwaretopics/software/appdev/story/0%2C10801%2C76413%2C00.html
> > http://seefigure1.com/images/xenix/xenix-timeline.jpg
> >
> >
> > --
> > My new email address is mrochkind@gmail.com
>
> Peter Yardley
> peter.martin.yardley@gmail.com
>
>

[-- Attachment #2: Type: text/html, Size: 6541 bytes --]

[TUHS] Re: History of non-Bell C compilers?

[Larry Stewart]

[-- Attachment #1: Type: text/html, Size: 7274 bytes --]

[TUHS] Re: History of non-Bell C compilers?

[Paul Winalski]

On 3/11/24, Peter Yardley <peter.martin.yardley@gmail.com> wrote:
> I used the DEC VMS C compiler extensively while I was at NSWIT. I ported a
> lot of Berkley (I think) C code to VMS. Some of their VLSI design suite, KIC
> etc. There weren’t a lot of changes to make, the compiler and library was
> pretty K&R from what I remember. The usual small header issues applied

The developers of the original DEC VMS C compiler took great pains to
be K&R-friendly by default.  There was a strict ANSI C option
available.

There later was a later, C89 compiler produced by Dave Cutler's
DECwest engineering team in Seattle.  I think it ran on Unix as well
as VMS.  It enforced the C89 standard very strictly--no option for
relaxations or extensions and no K&R compatibility.  One customer
described it as the Rush Limbaugh of C compilers--extremely
conservative and you can't argue with it.

> VMS IO is a bit different from UNIX IO

Understatement of the century.  :-)

>  but they had a mode (stream I think)
> that meant minimal changes to UNIX code.

VMS's device-independent I/O layer is called Record Management
Services (RMS) and as its name implies it is record-oriented.  They
did eventually add a stream mode to RMS, but that didn't happen until
well into the 1990s.  When DEC C for VMS first came out (ca. 1980)
there was no stream mode in RMS.  The C RTL had to implement stream
I/O as a layer on top of RMS.  It's fairly easy to build
record-oriented I/O on top of stream I/O but it's very difficult to do
it the other way around.  At first release the VMS C RTL's I/O had a
lot of buggy edge conditions.  It took them several releases to get
the I/O working properly.

Circa 1985 there was a port of the Bourne shell to VAX/VMS.  It of
course needed pipes, and I wrote a pipe pseudo-device driver for VMS.
It supported both stream and record read and write operations.

-Paul W.

[TUHS] Re: History of non-Bell C compilers?

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Tue, 12 Mar 2024 at 08:02, Marc Rochkind <mrochkind@gmail.com> wrote:

> Since it came up in this thread, here's my review of Coherent in BYTE
> Magazine (1985):
>
> https://www.mrochkind.com/mrochkind/docs/Byte-Pick-Coherent-Theos.pdf
>

This is an impressively thorough review from an end-user perspective, and I
am sorry that it was buried so far back in that issue of Byte!  Though I
suppose this was from the era when Byte was jam-packed with informative
reviews.  Did you continue to use Coherent, or do you have any thoughts on
the article in hindsight?

-Henry

[-- Attachment #2: Type: text/html, Size: 1024 bytes --]

[TUHS] Re: History of non-Bell C compilers?

[Marc Rochkind]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

On Tue, Mar 12, 2024 at 8:55 AM Henry Bent <henry.r.bent@gmail.com> wrote:

> ...Did you continue to use Coherent, or do you have any thoughts on the
> article in hindsight?
>
> -Henry
>

I definitely didn't continue to use Coherent. As I recall, I installed each
of the 3 systems successively on my XT (Pick, Coherent, and THEOS). That
was about the time I got PC/IX from Interactive Systems (true System III),
and that's what I went with.

At a trade show, I bought a utility that allowed me to run PC-DOS under
PC/IX. I'm sure it wasn't a virtual machine. Rather, it just swapped back
and forth. (Guessing a bit there.)

What Coherent and some other very early UNIX clones missed was the idea of
open source, which came along later. This is what allowed Linux to thrive
when others went by the wayside. But, nobody knew how to make any money
from open source (and maybe still don't), so that would have been a problem
back then.

As for my thoughts on the article: Reading it recently, it seems OK. I have
no idea how one ought to go about reviewing an operating system. Certainly
loading one up and playing with it for a couple of hours doesn't tell much.
Using one exclusively for a long time doesn't tell one anything, either. I
think reviews work better for movies, books, hotels, cameras, and things
like that.

Marc

[-- Attachment #2: Type: text/html, Size: 1883 bytes --]

[TUHS] Re: History of non-Bell C compilers?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

@Marc

On Tue, Mar 12, 2024 at 1:18 PM Marc Rochkind <mrochkind@gmail.com> wrote:

> At a trade show, I bought a utility that allowed me to run PC-DOS under
> PC/IX. I'm sure it wasn't a virtual machine. Rather, it just swapped back
> and forth. (Guessing a bit there.)
>
Hmm ... you sure it was not either VPIX or DOS/Merge -- ISC built VPIX in
cooperation with the Phoenix Tech folks for PC/IX. I always bought a copy
with it, but it may have been an option.   LCC did DOS/Merge originally as
part of the AIX work for IBM and would become a core part of OS/2 Warp
IIRC.  Both Merge and VPIX had some rough edges but certainly worked fine
for DOS 3.3 programs.  The issue tended to be Win and DOS graphics-based
programs/games that played fast and loose, bypassing the DOS OS interface
and accessing the HW directly.  For instance, I never got the flight
simulator (Air War over Germany) for Dad's WWII plane (P-47 Thunderbolt) to
run under either (i.e., only under DOS directly on the HW. FWIW: In that
mode, Dad said the simulator flew a lot like how he remembered it).

Both Merge and VPIX used the 386 VM support and a bunch of work in the core
OS.   Heinz would have to fill us in here.  The version of the 386 port ISC
delivered to AT&T and Intel only had the kernel changes to allow the VM
support for VPIX to be linked in, but it was not there.   IICR (and I'm not
sure I am) is that Merge could run on PC/IX also, but you had to replace a
couple of kernel modules.  It certainly would work on the AT&T and Intel
versions.
ᐧ

[-- Attachment #2: Type: text/html, Size: 2742 bytes --]

[TUHS] Re: History of non-Bell C compilers?

[Marc Rochkind]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

@Clem Cole <clemc@ccc.com>,

I don't remember what it was. But, the XT had an 8088, so certainly no 386
technology was involved.

Marc

On Wed, Mar 13, 2024 at 8:38 AM Clem Cole <clemc@ccc.com> wrote:

> @Marc
>
> On Tue, Mar 12, 2024 at 1:18 PM Marc Rochkind <mrochkind@gmail.com> wrote:
>
>> At a trade show, I bought a utility that allowed me to run PC-DOS under
>> PC/IX. I'm sure it wasn't a virtual machine. Rather, it just swapped back
>> and forth. (Guessing a bit there.)
>>
> Hmm ... you sure it was not either VPIX or DOS/Merge -- ISC built VPIX in
> cooperation with the Phoenix Tech folks for PC/IX. I always bought a copy
> with it, but it may have been an option.   LCC did DOS/Merge originally as
> part of the AIX work for IBM and would become a core part of OS/2 Warp
> IIRC.  Both Merge and VPIX had some rough edges but certainly worked fine
> for DOS 3.3 programs.  The issue tended to be Win and DOS graphics-based
> programs/games that played fast and loose, bypassing the DOS OS interface
> and accessing the HW directly.  For instance, I never got the flight
> simulator (Air War over Germany) for Dad's WWII plane (P-47 Thunderbolt) to
> run under either (i.e., only under DOS directly on the HW. FWIW: In that
> mode, Dad said the simulator flew a lot like how he remembered it).
>
> Both Merge and VPIX used the 386 VM support and a bunch of work in the
> core OS.   Heinz would have to fill us in here.  The version of the 386
> port ISC delivered to AT&T and Intel only had the kernel changes to allow
> the VM support for VPIX to be linked in, but it was not there.   IICR (and
> I'm not sure I am) is that Merge could run on PC/IX also, but you had to
> replace a couple of kernel modules.  It certainly would work on the AT&T
> and Intel versions.
> ᐧ
>


-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

[-- Attachment #2: Type: text/html, Size: 3658 bytes --]

[TUHS] Re: History of non-Bell C compilers?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

On Wed, Mar 13, 2024, 9:28 AM Marc Rochkind <mrochkind@gmail.com> wrote:

> @Clem Cole <clemc@ccc.com>,
>
> I don't remember what it was. But, the XT had an 8088, so certainly n
>
o 386 technology was involved.
>

Venix could also run DOS. There is a kernel module (well .o) that handles
it...

Warner

Marc
>
> On Wed, Mar 13, 2024 at 8:38 AM Clem Cole <clemc@ccc.com> wrote:
>
>> @Marc
>>
>> On Tue, Mar 12, 2024 at 1:18 PM Marc Rochkind <mrochkind@gmail.com>
>> wrote:
>>
>>> At a trade show, I bought a utility that allowed me to run PC-DOS under
>>> PC/IX. I'm sure it wasn't a virtual machine. Rather, it just swapped back
>>> and forth. (Guessing a bit there.)
>>>
>> Hmm ... you sure it was not either VPIX or DOS/Merge -- ISC built VPIX in
>> cooperation with the Phoenix Tech folks for PC/IX. I always bought a copy
>> with it, but it may have been an option.   LCC did DOS/Merge originally as
>> part of the AIX work for IBM and would become a core part of OS/2 Warp
>> IIRC.  Both Merge and VPIX had some rough edges but certainly worked fine
>> for DOS 3.3 programs.  The issue tended to be Win and DOS graphics-based
>> programs/games that played fast and loose, bypassing the DOS OS interface
>> and accessing the HW directly.  For instance, I never got the flight
>> simulator (Air War over Germany) for Dad's WWII plane (P-47 Thunderbolt) to
>> run under either (i.e., only under DOS directly on the HW. FWIW: In that
>> mode, Dad said the simulator flew a lot like how he remembered it).
>>
>> Both Merge and VPIX used the 386 VM support and a bunch of work in the
>> core OS.   Heinz would have to fill us in here.  The version of the 386
>> port ISC delivered to AT&T and Intel only had the kernel changes to allow
>> the VM support for VPIX to be linked in, but it was not there.   IICR (and
>> I'm not sure I am) is that Merge could run on PC/IX also, but you had to
>> replace a couple of kernel modules.  It certainly would work on the AT&T
>> and Intel versions.
>> ᐧ
>>
>
>
> --
> *My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*
>

[-- Attachment #2: Type: text/html, Size: 4734 bytes --]

[TUHS] PC/IX, VPIX, DOS/merge, etc. [was Re: History of non-Bell C compilers?

[Charles H Sauer (he/him)]

Heinz would certainly be more definitive than me regarding the ISC 
products, but ...

o IIRC, the name "PC/IX" was only used for the PC/XT release
- PC/IX was my first hands on access to Unix
- VPIX was bundled with PC/IX version
- I used VPIX minimally, don't remember much about it
- when I got a PC/AT for my office, I switched to Xenix because it took 
advantage of the 286
- there are various copies of PC/IX available, e.g., 
https://winworldpc.com/product/pc-ix/10, also subsequent ISC 386 
products there, pursuing is buried deep on my todo list
o Dell SVR3 was based on Interactive UNIX for 386, but eschewed VPIX in 
favor of DOS/Merge from LCC 
(https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/)
o Dell SVR4 was independent of both ISC & LCC except that it included 
DOS/merge
- the Dell SVR4 that I've made available for ancient hardware, 86Box and 
VirtualBox runs DOS/merge acceptably in my minimal testing

Charlie

On 3/13/2024 10:33 AM, Warner Losh wrote:
> 
> 
> On Wed, Mar 13, 2024, 9:28 AM Marc Rochkind <mrochkind@gmail.com 
> <mailto:mrochkind@gmail.com>> wrote:
> 
>     @Clem Cole <mailto:clemc@ccc.com>,
> 
>     I don't remember what it was. But, the XT had an 8088, so certainly n
> 
>     o 386 technology was involved.
> 
> 
> Venix could also run DOS. There is a kernel module (well .o) that 
> handles it...
> 
> Warner
> 
>     Marc
> 
>     On Wed, Mar 13, 2024 at 8:38 AM Clem Cole <clemc@ccc.com
>     <mailto:clemc@ccc.com>> wrote:
> 
>         @Marc
> 
>         On Tue, Mar 12, 2024 at 1:18 PM Marc Rochkind
>         <mrochkind@gmail.com <mailto:mrochkind@gmail.com>> wrote:
> 
>             At a trade show, I bought a utility that allowed me to run
>             PC-DOS under PC/IX. I'm sure it wasn't a virtual machine.
>             Rather, it just swapped back and forth. (Guessing a bit there.)
> 
>         Hmm ... you sure it was not either VPIX or DOS/Merge -- ISC
>         built VPIX in cooperation with the Phoenix Tech folks for PC/IX.
>         I always bought a copy with it, but it may have been an option. 
>           LCC did DOS/Merge originally as part of the AIX work for IBM
>         and would become a core part of OS/2 Warp IIRC.  Both Merge and
>         VPIX had some rough edges but certainly worked fine for DOS 3.3
>         programs.  The issue tended to be Win and DOS graphics-based
>         programs/games that played fast and loose, bypassing the DOS OS
>         interface and accessing the HW directly.  For instance, I never
>         got the flight simulator (Air War over Germany) for Dad's WWII
>         plane (P-47 Thunderbolt) to run under either (i.e., only under
>         DOS directly on the HW. FWIW: In that mode, Dad said the
>         simulator flew a lot like how he remembered it).
> 
>         Both Merge and VPIX used the 386 VM support and a bunch of work
>         in the core OS.   Heinz would have to fill us in here.  The
>         version of the 386 port ISC delivered to AT&T and Intel only had
>         the kernel changes to allow the VM support for VPIX to be linked
>         in, but it was not there.   IICR (and I'm not sure I am) is that
>         Merge could run on PC/IX also, but you had to replace a couple
>         of kernel modules.  It certainly would work on the AT&T and
>         Intel versions.
>         ᐧ
> 
> 
> 
>     -- 
>     /My new email address is mrochkind@gmail.com
>     <mailto:mrochkind@gmail.com>/
> 

-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/Twitter: CharlesHSauer

[TUHS] Re: History of non-Bell C compilers?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

Thanks.  Fair enough.  You mentioned PC/IX as *ISC's System III*

I'm not sure I ever ran ISC's System III port—only the V.3 port - which was
the basis for their ATT, Intel, and IBM work and later sold directly.   I'm
fairly sure ISC also called that port PC/IX, but they might have added
something to say with 386 in the name—I've forgotten. [Heinz probably can
clarify here]. Anyway, this is likely the source of my thinking. FWIW:  The
copy of PC/IX for the 386 (which I still have on a system I have not booted
in ages) definitely has VPIX.
ᐧ

On Wed, Mar 13, 2024 at 11:28 AM Marc Rochkind <mrochkind@gmail.com> wrote:

> @Clem Cole <clemc@ccc.com>,
>
> I don't remember what it was. But, the XT had an 8088, so certainly no 386
> technology was involved.
>
> Marc
>
> On Wed, Mar 13, 2024 at 8:38 AM Clem Cole <clemc@ccc.com> wrote:
>
>> @Marc
>>
>> On Tue, Mar 12, 2024 at 1:18 PM Marc Rochkind <mrochkind@gmail.com>
>> wrote:
>>
>>> At a trade show, I bought a utility that allowed me to run PC-DOS under
>>> PC/IX. I'm sure it wasn't a virtual machine. Rather, it just swapped back
>>> and forth. (Guessing a bit there.)
>>>
>> Hmm ... you sure it was not either VPIX or DOS/Merge -- ISC built VPIX in
>> cooperation with the Phoenix Tech folks for PC/IX. I always bought a copy
>> with it, but it may have been an option.   LCC did DOS/Merge originally as
>> part of the AIX work for IBM and would become a core part of OS/2 Warp
>> IIRC.  Both Merge and VPIX had some rough edges but certainly worked fine
>> for DOS 3.3 programs.  The issue tended to be Win and DOS graphics-based
>> programs/games that played fast and loose, bypassing the DOS OS interface
>> and accessing the HW directly.  For instance, I never got the flight
>> simulator (Air War over Germany) for Dad's WWII plane (P-47 Thunderbolt) to
>> run under either (i.e., only under DOS directly on the HW. FWIW: In that
>> mode, Dad said the simulator flew a lot like how he remembered it).
>>
>> Both Merge and VPIX used the 386 VM support and a bunch of work in the
>> core OS.   Heinz would have to fill us in here.  The version of the 386
>> port ISC delivered to AT&T and Intel only had the kernel changes to allow
>> the VM support for VPIX to be linked in, but it was not there.   IICR (and
>> I'm not sure I am) is that Merge could run on PC/IX also, but you had to
>> replace a couple of kernel modules.  It certainly would work on the AT&T
>> and Intel versions.
>> ᐧ
>>
>
>
> --
> *My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*
>

[-- Attachment #2: Type: text/html, Size: 5449 bytes --]

[TUHS] Re: History of non-Bell C compilers?

[Paul Ruizendaal]

> On 11 Mar 2024, at 18:12, Paul Ruizendaal <pnr@planet.nl> wrote:
> 
> On Thu, Mar 7, 2024, 4:14 PM Tom Lyon <pugs78 at gmail.com> wrote:
> 
>> For no good reason, I've been wondering about the early history of C
>> compilers that were not derived from Ritchie, Johnson, and Snyder at Bell.
>> Especially for x86.  Anyone have tales?
>> Were any of those compilers ever used to port UNIX?
> 
> An unusual one would be the “revenue bomb” compiler that Charles Simonyi and Richard Brodie did at Microsoft in 1981.
> 
> [snip]
> 
> I think the compiler also had a Xenix port, maybe it even was Xenix native (and at this time, Xenix would still essentially have been V7).

I was pointed to the book “Writing Solid Code”, Microsoft Press ISBN 1-55615-551-4. In the foreword it says:

"The system we used to develop Multiplan was pretty sophisticated for PC development in those days. We wrote the core product in C - most programs then were written in assembly or Pascal. We did our editing and compilation on a PDP-11 running Unix. The C code was compiled into p-code and downloaded to the target machines. We had to build p-code interpreters for each microprocessor in use at that time. By the end of 1983, we had interpreters working for the 8080/Z80, the 6502, the Z8000, the 68000, the 9900, and the 8086.”

So the Simonyi compiler was Xenix/Unix native.

The specs for its p-code interpreter can be found here:
https://forums.atariage.com/applications/core/interface/file/attachment.php?id=887196
https://forums.atariage.com/applications/core/interface/file/attachment.php?id=887197