[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