}I have been told that many Microsoft applications over the years, back to
}the original PDP-11/45 Xenix, used something like P-code. I believe this is
}one reason why that Excel and Word for the Macintosh and Windows until
}recently didn't exhibit the segment structure normally found in
}applications on those platforms.
}I think that something like Pcode is the only likely explanation why
}Multiplan ran on everything in sight at one point in the mid-'80s.
I remember hearing about this in the early 80's. Rumour had it that they
did cross development on larger systems (DEC 10's??).
Need to cross post this to alt.folklore.computers.
--
Stuart Lynne <s...@wimsey.bc.ca> ....................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................. ftp.wimsey.bc.ca:~ftp/ls-lR.Z
PD Software for SCO UNIX .................. ftp.wimsey.bc.ca:~ftp/pub/wimseypd
I don't have the full text of the parent articles available. However, it
looks like at least 2 threads here.
First, yes, early Microsoft software was cross-assembled on a DECsystem.
At least Microsoft BASIC and Fortran (CP/M versions) were. I'm sure the
assembler (M-80) was. I'm not sure about the Cobol, or any of the "appli-
cation" stuff. They used a version of the DEC assembler and a custom macro
library. With a few (very few) changes, they could assemble either an 8080
version or an 8086 version from the same source file. This is probably due
to the original "gang of three" - Bill Gates, Paul Allen, and Monty David-
off - who did the original BASIC-80 on the Harvard DECsystem while Bill was
in school.
As far as the UCSD P-system, well, several things went wrong there. One
was that it wasn't supposed to be a "business" and some folks got very
upset when it grew to the size it did, being from a school and all that.
Second, Western Digital did a version of the WD-16 (the same chipset as is
used in the DEC LSI-11 and the Alpha Micro systems) which directly executed
UCSD P-system code. All of the other systems at the time had an emulator
which ran P-system code on the native hardware. Unfortunately, right after
Western Digital built the chipset (the "Pascal Microengine"), the UCSD folks
decided to rearrange the P-code into some incompatible format. This caused
at least one company that was trying to build machines based on the WD-16
to fold. Of course, there wasn't much market for obsoleted WD-16's at that
point. Everybody sort of crawled away from the wreckage saying that they'd
never do anything with UCSD again (except for UCSD, of course, who had the
ego to think that they still had a major market).
As far as "P-code", I think the term was used by the original poster as
sort of a generic term for common code emulated on diverse hardware plat-
forms. I don't think anyone would actually use UCSD P-system code for such
products as Multiplan - it would make a lot more sense to develop a code
set suited for the particular application. Probably something like Forth
or STOIC, in this case.
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA
te...@spcvxa.spc.edu +1 201 915 9381
Cheer,s
Stephen
Niklaus Wirth used the term "p-code" in his early book, _Algorithms + Data
Structures = Programs_, in the chapter in which he demonstrated a compiler in
Pascal for a Pascal subset. The subset was compiled to "p-code."
This preceded by some years the UCSD system.
There was a series of articles on writing a Pascal compiler (in Northstar
Basic) in BYTE about autumn of 1978, which also used the term "p-code" for its
results. As I recall, this version of p-code looked a lot more like that in
Wirth's book than that in the UCSD manual.
--
Rich Alderson 'I wish life was not so short,' he thought. 'Languages take
such a time, and so do all the things one wants to know about.'
--J. R. R. Tolkien,
alde...@leland.stanford.edu _The Lost Road_
Having worked at Western Digital on software for their "MicroEngine"
system that used the WD-16...
There were a couple of other reasons the UCSD P-system failed:
When Western Digital announced the MicroEngine, they received a huge
(for the time) number of orders. Unfortunately the VLSI designers who
did the motherboard for the MicroEngine did not know how to design a
board. The board had power and ground traces the same width as the
signal traces, and there were _no_ capacitors on the board. The first
few boards made great oscillators. Of course they shipped a lot of
buggy boards before they hired a board designer. By the time they had
a working board, most of the customers had gone away.
At the same time SoftTech had bought the P-system from UCSD. The
license fees SoftTech demanded were steep, yet they did very little
with the product. We produced about the same amount of enhancements
with the equivalent about one full-time person as did SoftTech. This
is especially remarkable in that our contract required us to give them
any work we did.
BTW, the second validated Ada compiler came out of WD and ran on the
MicroEngine. Rolm beat WD by <1 month. We heard that Rolm took ~100
man years to develop their Ada compiler. WD took <10 man years. :-)
One reason for this was the compilations on the MicroEngine were
very fast (again, for the time...).
Of course the WD Ada compiler had trouble fitting in 128kb. At one
point in the compilation the compiler swapped the operating system(!)
out to disk to get a little more room...
--
Preston L. Bannister
Upstanding Systems
pre...@cerf.net
The current version of Microsoft C/C++ compiler (7.0) can generate p-code
I don't know if this is new to the compiler or not.
Krzysztof
Hello :-)
It was Network Consulting Inc. Our chief claim to fame from about '82-85 was
a re-implemention of the 8088 p-System interpreter. A horrible hack that was.
Basically used a chunk of 256*16 bytes for the base code for each of the 256
opcodes. Then with suitable register setup we where able to use the CS (?)
segment register as the p-code program counter. Saved a few loads and a branch
on every op-code. A suprisingly larger number of the p-codes could be implemented
in 16 bytes. The rest where handled by branching out and then getting back with
(I think) a two instruction sequence instead of the normal one instruction.
It got about 33% better performance out of the p-System.
We also re-implemented the floating point library. Our four word double
precision floating point was just barely slower than Softech's two word
single precision.
Fun stuff. Pretty much killed off by Borland. Softech Microsystems went
under. I believe Softech (the parent) is still around.
This is true. If you look at the resources in a Mac version of word or
excel you will find that there are far too few CODE resources for an
application of this size. You will, however, find two huge resources, of
type PCOD. These contain the p-code that is interpretted at run time.
At one time I had taken apart their CODE resources to figure out what
they were doing, but I don't think that I have this any more.
It seems that they do this so that they can use the "engine" type stuff
on any platform that they support, and so that their developers can work
on any machine they want, and just compile to p-code.
I know that the current Microsoft C compilers have a section on building
p-code interpreters. I hvae never used this option, so I can't say anything
more about this.
Peter
>The current version of Microsoft C/C++ compiler (7.0) can generate p-code
>I don't know if this is new to the compiler or not.
I also heard a rumour that if you look at some microsoft PC products, either
one of the compilers or the libraries, you can find SCCS ids - giving a
strong hint that they are at least keeping the source code repository on a
Unix machine.
You'd think at least that they'd use RCS?
Anybody out there with any Microsloth products out there care to experiment?
(An SCCS id looks like "@(#)foo.c" or "%W%", and sometimes other stuff like
date and time and version number)
--
Paul Tomblin, p...@geovision.gvc.com (Canadian first, Quebecer second)
"We sealed our federal pact without bloodshed and without exploitation of the
weak by the strong. All it took was fairness, justice and some compromises
on both sides." - George-Etienne Cartier, Father of Confederation, 1867
The most successful implementation of the UCSD p-System (in terms of installed
base and actual use) was Apple Pascal, mostly because it was cheap, easy to
use, and a hell of lot better than Apple's standard DOS. The "other folks"
trying to sell the UCSD p-System was SofTech Microsystems (in San Diego), who
had the p-System up and running on several platforms (including Apple IIs, IBM
compatibles and Macintoshes). Unfortunately, these folks wanted rather
outrageous license fees for any software developed using the p-System. That
would have been bad enough, but then Turbo Pascal came along and pretty much
demolished them. SofTech eventually got rid of the p-System (and may have
folded altogether by now, though I think they were still around just a year or
two ago), selling it a firm called Pecan Systems, who had much more reasonable
licensing and who improved the cross-environment aspects even more. But it was
too little, too late. [Historical note: there was also a group out of
Vancouver, BC, who had a p-System implementation which had much better
performance and more MS-DOS interactivity than the SofTech implementation, but
I forget the company's name.]
I personally have fond memories of the p-System, because I co-authored (with
Wayne Holder) a computer game for the Apple II (Sundog: Frozen Legacy) using
it. We hacked the p-System up pretty good (I wrote a p-code/6502 disassembler),
intercepting boot sequences, putting hooks into the p-code interpreter, and
faking the system out by dynamically changing the directory blocks on the
floppy disk. Final program source was 15,000 lines of Pascal and 5,000 lines
of 6502 assembly (graphics library, etc.). When Sundog was ported to the Atari
ST (after I left FTL Games), they used the UCSD p-System over there as well.
The first few Wizardy games for the Apple II were written using Apple Pascal as
well. ..bruce..
-------------------------------------------------------------------------------
Bruce F. Webster | I grow old...I grow old...
CTO, Pages Software Inc | dBASE II and Wordstar are no longer sold.
bweb...@pages.com | -- Jeff Duntemann
-------------------------------------------------------------------------------
15:38 d:\comp\msc700\bin>strings cl.exe | grep @(
File STDIN:
@(#)cc_main.c:1.156
@(#)target.c:1.49
@(#)get_err.c:1.10
@(#)flags.c:1.123
@(#)strings.c:1.9
@(#)error.c:1.17
@(#)cc_msdos.c:1.5
@(#)Microsoft C Compiler 7.00 - Copyright (C) 1986-1992 Microsoft
Corp.Mar 03
@(#)VERSION.c:1.3
15:39 d:\comp\msc700\bin>
On the other hand, the entire 14 megabytes' worth of stuff in Word for
Windows 2.0 contains none of these, and there are no compiler
copyright messages whatsoever in there...
--
Segmented Memory Helps Structure Software
Terry Kennedy, Operations Mgr. (te...@spcvxb.spc.edu) wrote:
: In article <By54p...@wimsey.bc.ca>, s...@wimsey.bc.ca (Stuart Lynne) writes:
: > I remember hearing about this in the early 80's. Rumour had it that they
: > did cross development on larger systems (DEC 10's??).
:
: I don't have the full text of the parent articles available. However, it
: looks like at least 2 threads here.
:
: First, yes, early Microsoft software was cross-assembled on a DECsystem.
: At least Microsoft BASIC and Fortran (CP/M versions) were. I'm sure the
: assembler (M-80) was. I'm not sure about the Cobol, or any of the "appli-
: cation" stuff. They used a version of the DEC assembler and a custom macro
: library. With a few (very few) changes, they could assemble either an 8080
: version or an 8086 version from the same source file. This is probably due
: to the original "gang of three" - Bill Gates, Paul Allen, and Monty David-
: off - who did the original BASIC-80 on the Harvard DECsystem while Bill was
: in school.
:
: As far as the UCSD P-system, well, several things went wrong there. One
: was that it wasn't supposed to be a "business" and some folks got very
: upset when it grew to the size it did, being from a school and all that.
I understood that UCSD licensed the pSystem to Softech Micro systems,
who were/are a major defence contractor. These guys had no idea about
micros , and charged minicomputer type prices for the pSystem and gave
very patchy support. I understand also that the Regents of UCSD did
not do as well as they hoped from the license which may explain the upset.
: Second, Western Digital did a version of the WD-16 (the same chipset as is
: used in the DEC LSI-11 and the Alpha Micro systems) which
directly executed :
UCSD P-system code. All of the other systems at the
time had an emulator
: which ran P-system code on the native hardware. Unfortunately, right after
: Western Digital built the chipset (the "Pascal Microengine"), the UCSD folks
: decided to rearrange the P-code into some incompatible format. This caused
: at least one company that was trying to build machines based on the WD-16
: to fold. Of course, there wasn't much market for obsoleted WD-16's at that
: point. Everybody sort of crawled away from the wreckage saying that they'd
: never do anything with UCSD again (except for UCSD, of course, who had the
: ego to think that they still had a major market).
The WD Pascal MicroEngine was built for Version II.1 or III of the Psystem,
which had quite a few architectural limitations. When version IV came out
I think that WD decided that there was no market and declined to upgrade
the chip. This was not a major part of the pSystem market - the majority
was Apple Pascal and the IBM PC with Stride/Sage not far behind .
The major problem was Softech - they didnt want to have the product and
it was eventually sold to another outfit called Pecan in 84/85 who
eventually went broke 2 or 3 years later. With all the business politics
the actual software just stagnated. Things like the 32 bit pMachine, the
Advanced File System etc never really made it to market, which was a
great pity as there was some truly fine ideas in there.
:
: As far as "P-code", I think the term was used by the original poster as
: sort of a generic term for common code emulated on diverse hardware plat-
: forms. I don't think anyone would actually use UCSD P-system code for such
: products as Multiplan - it would make a lot more sense to develop a code
: set suited for the particular application. Probably something like Forth
: or STOIC, in this case.
Why not?. UCSD Pcode is a pretty good portable code set . There were
Pascal, C, Fortran and Basic compilers using it . I dont know if FORTH
would offer any particular advantage for a non embedded system.
Products like Open Access were orginally written in the pSystem and
had a quite successful life, so I guess Multiplan could be also.
Cheers
David
David Hodge. MHSnet : d...@dbsm.oz.au
SBC Dominguez Barry Limited. INTERNET GATEWAY:
Sydney Australia. dbh%dbsm....@munnari.oz.au
--
David Hodge. MHSnet : d...@dbsm.oz.au
SBC Dominguez Barry Limited. INTERNET GATEWAY:
Sydney Australia. dbh%dbsm....@munnari.oz.au
What's so magic about embedded systems? Higher execution speed, tighter code,
and easier integration of high level and low level code is useful in any
environment.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' Oletko halannut suttasi tänään?
'U`
Tarjoilija, tämä ateria elää vielä.
You can contact Pecan Software Europe Ltd at:
Victoria House
10 Kellaway Avenue
Bristol
BS6 7XR England
--
Mikael Cardell <car...@lysator.liu.se>
S P U N K P R E S S
What's interesting is that any form of interpreter seems to have
a bad reputation these days. Even on machines a dozen times faster
than the Apple II, interpreted languages are avoided like the
plague because they are "slow." It is amazing what people will
sacrifice for a wee extra bit o' percieved speed--especially
considering how many poorly designed, buggy programs are kicking
around.
--
James Hague
exu...@exu.ericsson.se
--
Michael Coughlin mi...@gnu.ai.mit.edu
Cameron Laird
cla...@Neosoft.com (claird%Neoso...@uunet.uu.net) +1 713 267 7966
cla...@litwin.com (claird%litwi...@uunet.uu.net) +1 713 996 8546
UCSD recently signed an agreement with USUS (the UCSD p-System Users'
Society) which allows USUS members the rights to obtain and use object
and source code for all versions of the p-System for non-commercial use.
I suspect that there will be volunteer groups forming within the USUS
membership to maintain and develop the system for different processors.
For more information, go to the CODEPORT section of Compuserve; or write
USUS at Box 1148, La Jolla CA 92038-1148. Or mail to Stephen Pickett,
the USUS Librarian, at 71016...@compuserve.com.
--
Fritz Whittington Texas Instruments, P.O. Box 655474, MS 446 Dallas, TX 75265
Shipping address: 13510 North Central Expressway, MS 446 Dallas, TX 75243
fr...@csc.ti.com Office: +1 214 995 0397 FAX: +1 214 995 6194
Since I am not an official TI spokesperson, these opinions contain no spokes.