[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pascal system



In article <YwDhg.2841$lf4.239@newsread1.news.pas.earthlink.net>,
 BluPhoenyx <bluphoenyx@earthlink.net> wrote:

> John B. Matthews wrote:
> > 
> > I would argue that UCSD Pascal (and Apple's version in particular) was a 
> > stunning achievement for its time. It certainly included trade-offs in 
> > memory and speed, but it was seminal in the history of small computers. 
> > The same can be said for TP.
> 
> A similar approach was used in both 8 bit C compilers for the II. HyperC 
> and Aztec C could compile to byte code or 6502 code and link both into 
> the same program. Byte code was usually more memory efficient while 6502 
> code was quicker. All things considered, it was a pretty decent method 
> considering the hardware limitations.
> 
> Cheers,
> Mike T.

I bought a copy of Aztec C years ago - There were two options: Compile 
to byte-code and run under an interpreter (The only option for the $299 
"system is cheap, but distribution of developed applications is 
specifically prohibited without ultra-jumbo licensing costs and 
per-copy-distributed royalties" version - And we won't tell you this, 
but if you're smart enough to go looking at the generated code, you'll 
find that we scatter all kinds of "snitch data" through it to help us 
know that you did indeed use the cheap system to write the program, and 
are distributing it in violation of your license terms") or compile to 
native code and run standalone (Available with the $499 "Pro 
development, no further licensing costs or royalties for distribution of 
developed code" version)

With the "pro" version, it was also POSSIBLE (Though I'd hardly 
recommend it) to mix-and-match - Some parts in byte-code running under 
the interpreter, some parts in native 6502. Performance-wise, "mixed 
mode" code was effectively hobbled to interpreter speeds, since calls to 
"native" code got handled as if they were calls to underlying routines 
in the interpreter, whether they were made from "interpreted" or 
"native" code. Or, put another way, you didn't actually "write code" 
when putting together a mixed-mode program - You wrote "interpreter 
extensions" that got loaded up by the interpreter at runtime, and called 
(through its god-awful-slow calling mechanism) as needed. The only way 
to get truly decent performance out of the Aztec C system was to use the 
"Pro" version, write "pure native" code, and explicitly include the 
source for the (at the time, not-yet-standard-but-trying-to-get-there) 
library routines your code actually used in your compile, then link 
against the *.o outputs from the compiler, being sure to add the 
aztec-supplied (In .o format only, natch) crt.o, and consoleio.o files 
to the link.

-- 
Don Bruder - dakidd@sonic.net - If your "From:" address isn't on my whitelist,
or the subject of the message doesn't contain the exact text "PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd> for more info