kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) (02/15/90)
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.EDUc60a-3hu@e260-1g.berkeley.edu (Phil Escamilla) (02/19/90)
>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.....) The Sieve benchmark doesn't require floating point nor mul/div instructions. The 65816's architecture is such that it's difficult to write a compiler for it but most of today's applications are done with compilers and not assemblers The assembler link is simply becoz a lot of APple II programmers come from an environment where compilers are lacking (mainly on the IIe) and the programs are small enuff to not absolutely need compilers. Now this is absolutely nothing to be proud of. > >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 believe is that if u have to kludge your programs badly and come out with all these "ingenious" tricks u wouldnt have time for much else. It also doesn't make the code portable easily. While u comparing the Apple // to a 2Mhz 68000? As I said the 68000 takes 4 cycles to access a 16-bit word and the 65816 takes 3 (the 65C02 would take 4 in 2 instructions). Of course this is notwithstanding the fact that u don't get bogged down by the aweful paging scheme (I thot the 8086 was dumb). Anotherr reason why it's absolutely hard to produce good compilers. > >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?) Yep... the 68000 is far from perfect... take a look at the NS 32032 or the RISC chips. But relative to the 65816 is definitely a hell lot better.