Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!snorkelwacker!mit-eddie!rutgers!njin!princeton!phoenix!kadickey
From: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey)
Newsgroups: comp.sys.apple
Subject: HyperC stuff
Message-ID: <13874@phoenix.Princeton.EDU>
Date: 15 Feb 90 06:27:39 GMT
Organization: Princeton University, NJ
Lines: 45

Has anyone used my patch that lets HyperC work on a //gs?  If so, just
drop me a line letting me know that it works ok...

As to running HyperC files under ordinary ProDOS as a SYS file--most
programs also open files, get keyboard input, create output, etc., while
running.  Under a Unix-like C environment, there are subroutines to
perform all of these actions (which exist in the HyperC OS).  Porting to
ProDOS involves not just getting the QUIT code correct, but getting:
	fd = open("/mydisk/myfile",0);
	read(fd, buf, 1000);

to work correctly--a definitely non-trivial job (not that this example
is tough, but the whole issue of file-descriptors -> ProDOS files, etc.
is the work that needs to be done to get HyperC output to run under
stand-alone ProDOS 8.

BTW: Whenever any of my HyperC programs end, the disk /CSYS *ALWAYS*
comes on to (I guess) read something in.  Why?  I don't see what info
it needs--unless it's the shell...does this happen to everyone else?

Has anyone looked at the code HyperC produces--is it really good?  Or
does it do 16-bit adds with a subroutine call (which is *REALLY* bad)?

Which brings me to benchmarks: there are no really good compilers for
the Apple //.  Besides, all useable Apple // programs are written in
assembly anyways, so it doesn't matter.  Also, the //gs doesn't have
mutliply or divide instructions, which makes 'standard' benchmarks run
EXTRA slow on an Apple // (Dhrystones/sec on a //gs is like 300....I'm
almost embarrassed to report numbers that low.....)

I've been wanting to write my own mult and divide routines using tables
(128K for mult, 64K for div) and see how fast I can get it to work...
but to make accurate comparisons, I need 68000 timings which I won't
have a list of until this weekend...I remember calculating that the
Apple // is twice as fast as a 68000 due to inefficiencies the 68000 has
in accessing memory...

The 68000 an orthogonal machine? -- HAH!  Not only are data and address
registers isolated, but many instructions have severe restrictions on
what addressing modes are valid (ABCD is a really good example of bad
addressing mode availability..why can't it just add two 32-bit BCD
numbers in data registers?)

			Kent Dickey
kadickey@phoenix.Princeton.EDU