brianw@microsoft.UUCP (Brian WILLOUGHBY) (12/29/90)
jerry@redford.UUCP (Jerry Shekhel) writes: >gwyn@smoke.brl.mil (Doug Gwyn) writes: >> >>Right on! >>I estimate that a "stock" IIGS with 1.125MB of memory is fully as capable as >>a typical IBM PC clone; > >It isn't. Even the oldest PC clones with 8088 processors are at least twice >as fast as stock IIgs's, and the 8088 processor has a much more functional >instruction set than the '816. That was yesterday. Today's typical PC clone >is a 16MHz 32-bit machine with at least 2MB memory, a GUI, and graphics that >blow the IIgs away. Get real! When is the last time you actually used a 4 MHz 8088 machine? Do you actually program in assembly? The 8088 architecture is NOTORIOUS because it is so terrible. At least the 6502 has memory indirection, which is something that the 68000 was missing until they decided to add this powerful feature to the 68020. I think you need to do some research into the "typical PC clone". I work for Microsoft, and we are concerned with finding a decent minimum platform for our software which is affordable to everyone. It is hard to even fit a 12 MHz 286 with 1 Meg RAM and 40M hard disk into everyone's budget. Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
rhyde@ucrmath.ucr.edu (randy hyde) (12/29/90)
>> re: 8088 vs. 65816
Why don't we all call a truce on this one. It's generating too much
noise around here and it's not productive at all. By now it should be
obvious to everyone (on both sides of the argument) that ignorance is
going to reign forever around here, there's no convincing people on the
other side that they're completely wrong. Support of the Apple II and
the 65816 is a religion to some, and they'd rather die a martyr than
open their eyes to any form of "enlightenment". Personally, I'm
typing this at the keyboard of a Mac IIfx, not an Apple IIGS. You're
defintely not going to be able to convince me that the GS is better than
my Mac II. OTOH, I also own a GS which I like quite a bit. I don't
want to talk you out of that machine, it may not be the best but it's a
damn good machine. All of this negative stuff started about six months
ago with everyone complaining about the lack of support from Apple concerning
the Apple II GS. I would like to take a moment and recap Apple's lack of
support over the last couple of years:
Apple doesn't give us new system software: How about the latest 5.x?
Apple doesn't give us new hardware: How about the video overlay and SCSI cards?
Apple doesn't give us new applications: How about hypercard?
Apple doesn't try to sell the GS anymore: I dunno about this year, but last
year the GS was the top selling machine in unit volume. Perhaps they don't
have to *try* to sell it, it sells on its own.
Apple doesn't advertise the machine: why should they? It sells on its own.
Apple hasn't given use a new Apple II machine recently: What kind of machine
could they build that would be a major improvement over the GS (much like the
GS was over the //e?) Until the 65c832 becomes a reality, AND if it offers
substantial improvements, I doubt we'll see a new Apple II. For those who
think the 65c832 is too little, too late, let me point out that I was
thinking the same thing about the 65c816 in 1985.
If you still think Apple doesn't support the Apple II family anymore, I
invite you to go purchase a PC jr. or even an IBM PC/XT and tell me about
support. (Sure, you can buy more powerful "XT" compatible machines today,
but Apple will sell you a Mac LC which is a more powerful //e today).
*** RAndy Hydeunknown@ucscb.UCSC.EDU (The Unknown User) (12/29/90)
In article <10807@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >Apple doesn't give us new system software: How about the latest 5.x? Hey, I will say that ANY new system software is better than none, but it seems the Mac gets improvements in bigger leaps and bounds, AND is preannounced, going against their "we do not discuss unannounced products" line. Can you say hypocrisy in action? >Apple doesn't give us new hardware: How about the video overlay and SCSI cards? I will also say you are right on this one.. But the video card is CERTAINLY not something everyone needs. I can say NOTHING bad about the SCSI card though.. Great improvements and keep the price the same. GREAT JOB APPLE ON THIS ONE! But I think that no new Apple II CPUs when there's a Mac-a-week says something.. >Apple doesn't give us new applications: How about hypercard? I'll agree with you on this one. I don't really know what applications Apple -should- make, other than the system software. There are a few that Claris could make, but even that isn't a big deal.. I want THIRD PARTY companies to make software! >Apple doesn't try to sell the GS anymore: I dunno about this year, but last >year the GS was the top selling machine in unit volume. Perhaps they don't >have to *try* to sell it, it sells on its own. Now this is the main one I was going to bitch about from the start. Am I correct in assuming that in this category, you are SEPARATING every single Macintosh variety? If so, I really don't consider that a fair statistic then! We all know that many of the Macintoshes have slight differences between them (relatively speaking), and it isn't quite fair to talk about them all individually. If not, I'd also honestly like some kind of sources for that statistic! >Apple doesn't advertise the machine: why should they? It sells on its own. See my complaints for the above answer. I don't believe it's selling that well, precisely (sp?) because Apple isn't advertizing the machine.. (which in turn causes many people to still think it's an 8 bit machine and make judgements on it with incorrect information). >Apple hasn't given use a new Apple II machine recently: What kind of machine >could they build that would be a major improvement over the GS (much like the >GS was over the //e?) Until the 65c832 becomes a reality, AND if it offers >substantial improvements, I doubt we'll see a new Apple II. For those who >think the 65c832 is too little, too late, let me point out that I was >thinking the same thing about the 65c816 in 1985. Faster main CPU. Better resolution. (I don't know the whole specs of it, so I might be putting my foot in my mouth.. But it seems REALLY screwy to have mini palettes in 640 mode where you can have 4 different palettes for each of 4 pixels... Seems reminiscent of the funky color "features" in the original hires) Those two are the main improvements I'd like to see. Anything else would be icing on the cake.. (such as more sound RAM, -built in $10 of parts for stereo-, and probably other things I can't think of now). >invite you to go purchase a PC jr. or even an IBM PC/XT and tell me about It's really really weird.. In some ways Apple and IBM are sort of "switching places".. Not that I like IBM computers now (I still dislike them, admittedly for a bunch of nitpicky aesthetical reasons such as function keys, which I find to be the stupidest thing ever. I mean, I don't even NEED a mouse.. CONTROL S for save or OPENAPPLE S for save make a hell of a lot more sense than F3!).. But it seems Apple is abandoning its roots (meaning home computers, not even specifically the Apple II here), yet IBM realizes there's a home market and makes the PS/1! So "Apple's becoming bluer every year" and "IBM's becoming more multi-colored every year"... -- /Apple II(GS) Forever! unknown@ucscb.ucsc.edu MAIL ME FOR INFO ABOUT CHEAP CDs\ \WRITE TO ORIGIN ABOUT ULTIMA VI //e and IIGS! Mail me for addresses, & info. /
rhyde@ucrmath.ucr.edu (randy hyde) (12/30/90)
>> Two main improvments: > Faster CPU-- This is handled by a couple of third party products right now. So *YOU* don't have any problems. Of course, it doesn't help Apple II gs sales any, but that won't particularly affect you either. What I'd like to see is a *better* CPU. I don't think the 65c832 is gonna cut it either (I haven't seen the specs yet, but the last time I talked to Bill Mensch he was talking about pin compatibility with the '816-- Great for GS owners, but lousy for future systems). I'd like to see a 65020 or a 65032 chip with a real 32-bit bus so Apple could build a NUBUS Apple II and let me swap boards between my Mac II and my Apple II (not to mention 40 Mb/sec transfer rate). One of the big problems with the GS, which is why a stock PC (8088) is better is that the 8088's architecture is *much* better for High Level languages. While assembly language programs on the '816 probably just edge out asm pgms on an 8088 (2.8 vs. 4.77 Mhz), *most* programs today are *not* written in assembly (a sad, but true, fact). One of the main reasons the GS is getting so little third party software support is due to the fact that there are lousy HLL software development tools available (ORCA, APW, and TML pale in comparison to what's available for the PC). A better architecture (see one of my previous articles) would help this situation tremendously. >> Better graphics I don't think anyone can argue with this. At one time AI had an adapter card that let you plug HMGA and VGA graphic adapters into the GS. They never marketed the product however. Nubus slots on a new Apple would certainly eliminate this problem. *** Randy Hyde
philip@yunexus.yorku.ca (Phil McDunnough) (12/30/90)
In article <10807@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >>> re: 8088 vs. 65816 > >Why don't we all call a truce on this one. Good idea. I don't understand the point of it all anyway. [stuff re using the MacIIfx, liking the GS and support for the GS] As far as the fx goes, it is one of the poorer price/performance computers out there. It's basically a colour fast Mac+. I've used them all(the Mac's) and they are getting very hard to justify. The same goes for the GS. You say that Apple is trying to sell them, but the GS will whither away as long as it costs more than a color Mac with an 020 in it. If Apple were serious about selling the GS, they would cut the price in half. Their current tactic is a well-known way of phasing out an unwanted computer- keep the price and service costs high. AppleCare for the GS colour monitor costs the same as the one for the Mac, which is a substantially better monitor. As for software support,etc...these are crumbs to try to prevent AppleII() users from moving away from Apple Computer. Your HCGS and System5.0.4 examples are nice but these are hardly things to jump up and down for. HyperCard on the Mac has not been an overwhelming success, and proving users with a decent OS is the very least one can expect. If you think Apple is actively supporting the GS you are certainly not in touch with the AppleII() world. Philip McDunnough University of Toronto->philip@utstat.toronto.edu [my opinions...]
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (12/31/90)
Assembly language on the 65816 edges out the 8088 at almost half the clock rate? I may not have majored in computer science, but doesn't both a compiler and an assembler generate machine language? Logically both generate the same code for the same problem solution. Therefore a given instruction that is good for Assmebler should also be good for Compiler. Needless to say, I know little about compiler design, but I have hand compiled C code on the 65816 and much of the syntax is directly translatable to assembly on a line for line basis (derefencing handles is an exception). Which specific instructions are required in a computer achitecture to make easy for an HLL compiler? UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
jerry@polygen.uucp (Jerry Sheckel) (12/31/90)
brianw@microsoft.UUCP (Brian WILLOUGHBY) writes: > >Do you actually program in assembly? The 8088 architecture is >NOTORIOUS because it is so terrible. At least the 6502 has memory >indirection, which is something that the 68000 was missing until they >decided to add this powerful feature to the 68020. > I never said that the 8088 architecture is the greatest. In fact, it's not. There are only 4 general purpose registers, and some of them have specific uses in some of the more complex instructions (like when CX is used as a counter in the REP species). 64K segments are a pain on the 8088 (but provide the basis for true memory management on the '286, and are gone in the '386, in a compatible way, of course). STILL, this is far above the 6502's accumulator-based instruction set, without multiplication/division, memory management, etc. What is this memory indirection stuff? Are you talking about the JMP (xxxx) instruction? Zero page addressing? Give me a break. > >I think you need to do some research into the "typical PC clone". I >work for Microsoft, and we are concerned with finding a decent >minimum platform for our software which is affordable to everyone. >It is hard to even fit a 12 MHz 286 with 1 Meg RAM and 40M hard disk >into everyone's budget. > What are you talking about? The machine you described can be bought today for less than a grand. Now, how much was that IIgs? > >Brian Willoughby > -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+
anarch@eleazar.dartmouth.edu (The Anarch) (01/01/91)
In article <325@generic.UUCP> ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes: >Assembly language on the 65816 edges out the 8088 at almost half the clock >rate? > >I may not have majored in computer science, but doesn't both a compiler and an >assembler generate machine language? Logically both generate the same code for >the same problem solution. Therefore a given instruction that is good for >Assmebler should also be good for Compiler. Whoa! Take it from a comptuer science major, it doesn't work like that. Unfortunately. The problem is that the flexibility and ease of use (relatively speaking, of course) of a compiler comes at a cost of decreased efficiency, due to its rigidity of implementation; the compiler has one fully generalized way to translate, for example, "for i:=a to b do begin ... end" which it uses even when circumstances would permit simplification of the structure (optimizing compilers, yes, I know, but I'm trying to keep this basic). >Needless to say, I know little about compiler design, but I have hand compiled >C code on the 65816 and much of the syntax is directly translatable to >assembly on a line for line basis (derefencing handles is an exception). Syntactically, the structures may be similar and easily mappable, but it is reliance on this characteristic that leads to the problem above: the more simple and general your syntactic rules are, the more inefficient the translation is, but the more refined your syntax becomes, the trickier it is to make your computer understand it, i.e. write the compiler. Still, you are right to say that C is not to difficult to translate structurally. However, what's going to kill you, as far as code efficiency goes, are the predefined functions that C gives you to make your job easier, like the I/O and mathematical functions. These get translated into code that is massive and ugly next to what you could do with assembly. You *could* write a C program without using any such functions, and it would end up syntactically very similar to a assembly language program. But then you're skipping the best parts of using a high-level language, and you might as well have written it in assembly anyway. To see the effect of using these functions, a good experiment is to get out your favorite C compiler, write up the famous "Hello world" program and compile to an executable. How big a file do you end up with? Now fire up the mini-assembler and put together a program that accomplishes the same thing. I would be shocked if it took you more than two dozen bytes, data included. printf(), though, is a *big* function!
rhyde@ucrmath.ucr.edu (randy hyde) (01/02/91)
>>> Assembly language on the 65816 edges out the 8088 at almost half the clock rate... Of course, most 8088 system run at about twice the clock speed (or better) of most 65c816 systems, so this advantage isn't as great as you would think. (This btw, has to do with hardware, things like memory access times). >> Logically both generate the same code for the same problem solution... A lot of compiler vendors would like you to think this. Alas, compilers are, in general, brain dead. They rarely make smart decisions concerning code generation. Like algorithm implementation in a HLL, there are thousands of ways to accomplish something in assembly (machine) language. The compiler always picks the same way to do something. An experienced assembly language programmer can choose an efficient technique based on the current context. I really laugh when someone tells me that there is not reason to use assembly language because optimizing "C" compilers are so good. They tell me that their "C" compiler produces code which is only 25% slower and 50% larger than a corresponding assembly language program. I then turn around and reimplement the program so it requires half the space and runs 5-10x faster than the comparable "C" program. While it is theoretically possible to write a compiler that is as smart as a typical (not expert) assembly language programmer, we're still a long ways off from this. As for the architecture of the 65xxx vs. 8088 being good for compilers- the 8088 has a BP register which makes it easy to access parameters and local variables on the stack. The 65c816 doesn't have (and desparately needs) this. A stack pointer which is 24 bits long would be useful too. Easier access to data on the stack (which is where HLLs pass parameters, store temporaries, and allocate local variables) would be useful. Good, indexed and indirect addressing modes on the stack would be useful as well. SBF and DIVF (subtract from, divide from) instructions would also be useful. A top of stack addressing mode, like the 68000 and 32000 have, would also be incredibly useful to compiler writers. Signed comparisons (branches) would be handy, for reasons you can imagine. Long branches would be real useful (since the compiler always has to assume that forward branches are out of range). The ability to pop parameters off the stack when returning from a subroutine would be useful. Addressing modes to support various common HLL data structures (records, arrays of pointers, handles, lists, sets, etc.) would be quite useful. Most machines only handle arrays and pointers reasonably well. The 8088's four component addressing scheme is a good example (although it doesn't go far enough). RISC proponents argue that you can handle all of this in software. You most certainly can. You can write a really good "C" compiler for a 6502. But it's so difficult to do that no one has. Furthermore, the performance would be terrible (the 6502 is *not* a RISC chip, with the advantages of a RISC). . *** Randy Hyde
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/02/91)
rhyde@ucrmath.ucr.edu (randy hyde) writes: >I really laugh when someone tells me that there is not reason to use >assembly language because optimizing "C" compilers are so good. They tell >me that their "C" compiler produces code which is only 25% slower and 50% >larger than a corresponding assembly language program. I then turn around >and reimplement the program so it requires half the space and runs 5-10x >faster than the comparable "C" program. I agree with you in principle on this, but in many cases the real issue is development time vs. code qualities. I find that I often write in C as much as possible (even with Orca/C on the GS, BTW) and use assembly only when speed or compactness are important. Examples would be screen-clearing loops (speed) and simple functions like XBA which are ludicrous when compiled but are quite nice when a quick asm{} statement is used to add in-line assembly code. >As for the architecture of the 65xxx vs. 8088 being good for compilers- >the 8088 has a BP register which makes it easy to access parameters and >local variables on the stack. The 65c816 doesn't have (and desparately needs) >this. Orca/C uses the direct page for this. A seperate register would be better. >A top of stack addressing mode, like the 68000 and 32000 have, would also be >incredibly useful to compiler writers. 1,s and (d,s),y are available. However, I would have preferred a [d,s],y mode instead. >The ability to pop parameters off the stack when returning from a subroutine tsc clc adc #n tcs Isn't THAT bad, but aesthetically I agree with you. Todd Whitesel toddpw @ tybalt.caltech.edu
zane@ddsw1.MCS.COM (Sameer Parekh) (01/03/91)
In article <1990Dec31.233636.24004@dartvax.dartmouth.edu> anarch@eleazar.dartmouth.edu (The Anarch) writes: >compile to an executable. How big a file do you end up with? Now fire up >the mini-assembler and put together a program that accomplishes the same >thing. I would be shocked if it took you more than two dozen bytes, data >included. printf(), though, is a *big* function! Don't USE printf() use puts()! Printf is huge because of all the formatting routines, puts is VERY simple. (Maybe even a while loop of putchar()s would be more efficient, but that is what I think puts() does anyway.) -- zane@ddsw1.MCS.COM
rhyde@ucrmath.ucr.edu (randy hyde) (01/04/91)
>> The real issue is development time vs. code qualities... That's why there's very little software available for the GS, people don't want to use assembly language anymore and assembly is the only practical language for reasonable software on the GS. Sure, you can use C or Pascal for simple tasks, but for complex tasks HLLs are *way* too slow on the '816. As for code development time, did you say you're using ORCA/C? :-) Of course, if you compare ORCA/C against ORCA (the assembler) perhaps you don't get a skewed view. I promise you though, I can get a product working twice as fast with Brian Fitzgerald's Lisa/816 than I can with ORCA/C. Orca/C is, shall we say, glacial. I tried porting FLEX & BISON to the GS using ORCA/C. I gave up. It was too slow (ORCA/C) and the version I had (whatever their second release was) had way too many bugs. The standard library was very wimpy. I dunno if they've fixed these problems in a later release. I just went back to my '386 mumbling about rotten tools. I hate blasting Bytework's products, they're the best we've got and we all really need to support them, but geeze.... >> ORCA/C uses the direct page register (as a base pointer).. Sure, so do the other languages available. This has two major disadvantages: (1) Your stack frames are limited to 256 bytes, max (no big arrays!) (2) You can't use direct page values as "register" variables. Since the frames are rarely page aligned, accessing such variables costs an extra cycle on each access. As for the extra addressing modes, if a frame pointer were available, presumably it would support all of these as well. See my article on the 65820 for more details. >> [instruction sequence] isn't THAT bad. This is 10 cycles above and beyond the cost of a return. Not to mention six extra bytes (for *each* call). For "C" you have no choice but to do this. For Pascal, whose procedures and functions have a fixed number of parameters) the subroutine can pop the parameters rather than the caller. Given how universities are pushing "modular" code these days, and the amount of people writing *tiny* subroutines in this world, you'd probably be surprised how much this little addition would help. *** Randy Hyde
rhyde@ucrmath.ucr.edu (randy hyde) (01/04/91)
>> Don't use printf, use puts()...
I included a printf (assembly language version) in the ANIX shell I wrote for
the GS. Even with floating point it wasn't that big (less than 1K as I recall.
Of course, I called SANE for the floating point stuff. Hoever, I assume
C's printf does the same. If anyone is interested, I could post this
code to an anonymous FTP here at UCR.
*** Randy Hydetoddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/04/91)
rhyde@ucrmath.ucr.edu (randy hyde) writes: >but for complex tasks HLLs are *way* too slow on the '816. I've always wondered if that's a fact of life or if it's really just something wrong with the way the existing compilers are designed. > It was too slow (ORCA/C) and the version I had >(whatever their second release was) had way too many bugs. The standard I agree, the standard library is annoying. I have considered writing some real replacement routines, but I have projects I want done first and the 1.1 release of the compiler/libraries has been adequate so far. It's funny: every bug in the compiler or the libraries I discovered quickly -- if it took more than an hour it was always a genuine bug of mine. >>> ORCA/C uses the direct page register (as a base pointer).. >(1) Your stack frames are limited to 256 bytes, max (no big arrays!) I've declared char a[3000] as a local variable in Orca/C without any problems. The generated code uses dp,x (if the base of the array is in the dp accessible space) or a generated long pointer (if it isn't). The real problem is the total size of the stack frame (4K default). However, from looking at Orca's output for a simple program like void main (void) { char a[1000], b[1000]; int i; for (i=1000; i--; ) a[i]=b[i]=0; } it is obvious that Mike is using seperate paradigms for accessing nontrivial variables (like arrays outside the 256 byte dp) and evaluating expressions; the result being that Orca/C has an unbelievably complex code generator which produces some really ugly code in many situations that 'show weaknesses of the 65816'. If Orca/C used a FORTH-like paradigm which attempted to keep the top of stack in the CPU registers (not hard), for both evaluation of expressions and nontrivial variable access, it would simplify things a lot. Maybe they would simplify enough so that Mike could get the whole damn compiler working and write a real library!! >(2) You can't use direct page values as "register" variables. Since the frames > are rarely page aligned, accessing such variables costs an extra cycle on > each access. How often does this make a real and practical difference? The theoretical speed hit is 25% under absolute worst conditions (i.e. constant 8 bit dp accesses). If you really want an aligned direct page, it is not that hard to force it down to the nearest alignment and copy the variables over. If the speed increase is actually going to make a difference then the setup/takedown time will be dominated by the code that needed the register variables in the first place. I really don't think it's necessary, because if you can't write a tight assembly loop to do it, then dp alignment isn't going to help you anyway. Now that I'm working in word size operands all the time, I really only notice the speed difference in the most tightly coded assembly loops. An example would be the DiskCopy program -- the asm{} statement that computes the checksum of the disk image data is 57 cycles per word of data, five of which are due to direct page nonalignment. If the dp was aligned the code would be 9.6% faster. If it were really that important, I'd be doing it truly in assembly and not as an asm{} statement and then it wouldn't be an issue any more. >>> [instruction sequence] isn't THAT bad. > This is 10 cycles above and beyond the cost of a return. point taken. >Not to mention six extra bytes (for *each* call). No, for each function. Orca/C uses that kind of sequence to both create and destroy the stack frames on function entry and exit. >For "C" you have no choice but to do this. For Pascal, whose procedures and >functions have a fixed number of parameters) the subroutine can pop the >parameters rather than the caller. Sorry, but C subroutines usually pop the parameters because it's more efficient for them to do so. Variable parameter functions have to "know" how many to pop -- the standard library looks at the format string, but with ANSI C it's been standardized with the va_arg stuff. > Given how universities are pushing "modular" code these days, and the >amount of people writing *tiny* subroutines That's really sad. Has everybody forgotten the original reasons for inline() and parametric defines? They can't be THAT anal retentive about modularity. Todd Whitesel toddpw @ tybalt.caltech.edu
rhyde@spahn.ucr.edu (randy hyde) (01/05/91)
>> I've always wondered if that was a fact of life or it's really something >> wrong with the way compilers are designed... Probably both, actually. Having taught compilers at the undergraduate level and actually written a compiler for the 6502/65802, I can tell you that it's possible to write a good compiler for the 6502 (mine wasn't), but it's an incredible amount of work. Far more than anyone I know is willing to put in for the meager return they're going to get on their investment. Even though Apple was (emphasis on past tense) feeding Byteworks $50,000/year for the APW license, I'm impressed that Mike Westerfield put as much as he did into ORCA/Pascal and ORCA/C (didn't stop me from asking him for C++ though!). Nonetheless, ORCA/C has a *long* way to go before typical PC developers would consider using it to port their products to the GS (and speed, both of the compiler and compiled code, is only part of the problem). *** Randy Hyde
jb10320@uxa.cso.uiuc.edu (Desdinova) (01/05/91)
In article <10896@ucrmath.ucr.edu> rhyde@spahn.ucr.edu (randy hyde) writes: [difficulty of compiling HLL to 6502] >Apple was (emphasis on past tense) feeding Byteworks $50,000/year for the >APW license, I'm impressed that Mike Westerfield put as much as he did into >ORCA/Pascal and ORCA/C (didn't stop me from asking him for C++ though!). >Nonetheless, ORCA/C has a *long* way to go before typical PC developers would >consider using it to port their products to the GS (and speed, both of the >compiler and compiled code, is only part of the problem). > >*** Randy Hyde Even though Orca/C is written in Pascal (MPW Pascal, I presume), it's still fairly fast even compared to a Sun I use at work. The Sun is admittedly several times faster compiling, but then I didn't pay close to $10,000 for my GS, either. I am nonetheless very impressed with what Mike has accomplished (although I still insist he hire some programmers so C can be fixed before the new millenium). And Randy- a good number of the C++ "compilers" out there are nothing more than translators that take C++ and spit out C code. There is no reason such a beast couldn't be written for the GS. Object oriented stuff isn't hard to do at all- even without a special language that supports it, one can program in an OOP style very effectively. This is, BTW, an attempt to get one of you reading this motivated. -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry jb10320@uxa.cso.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering
rhyde@ucrmath.ucr.edu (randy hyde) (01/05/91)
>>A good number of the C++ compilers out there are translators...
I've tried to use CFront with ORCA/C. Alas, ORCA/C's biggest failing
is that the standard libraries supplied are rather weak. CFRONT produces
all kinds of calls to library functions which don't exist in ORCA/C.
I've also tried porting a compiler I wrote with FLEX & BISON on a PC
to ORCA/C and ran into the same problem.
To me, this is ORCA/C's biggest problem. Mike needs to supply a standard
library which is compatible (at least, as much as possible) with Microsoft C
and/or Turbo C. When this happens, a lot of cross platform compatibility
occurs for free. Personally, I could live with ORCA/C's slow compilation
times if I could do all my work on my '386 and then port the code across
Appletalk to the GS. Who cares if it takes a half an hour to compile and
link? I can go back to work on my '386 at that point. Alas, it's not
quite this simple. I was spent about 32 hours attempting to get FLEX to
run in native mode on the GS. I failed. (Someone else got it to run on
their machine, I downloaded it from BIX, but it failed again on mine).
FLEX is a reasonably machine independent piece of code. There is no
reason it shouldn't be capable of running on a GS with little or no
effort. Alas, I failed at it. If ORCA/C had a better library, things
would be much better on the GS front.
*** Randy Hydeericmcg@pnet91.cts.com (Eric Mcgillicuddy) (01/06/91)
>Of course, most 8088 system run at about twice the clock speed (or better) >of most 65c816 systems, so this advantage isn't as great as you would think. >(This btw, has to do with hardware, things like memory access times). I do not know of any 16MHz 8088 systems available. I believe Intel froze the architecture at 8MHz to move people towards the 286 in high speed systems. The 80C86 might be available in faster versions, though I think most have moved to 386s above 16MHz. >Addressing modes to support various common HLL data structures (records, >arrays of pointers, handles, lists, sets, etc.) would be quite useful. Most >machines only handle arrays and pointers reasonably well. The 8088's four >component addressing scheme is a good example (although it doesn't go far >enough). This has come up in my current project and I am not completely satisfied with the results, however it works within restrictions. A 65xxx array of pointers is generally referred to as "zero page" or "direct page". Handles get to be a problem, but linked lists can be traversed moderately well, structures also. There is an interesting book on writing compilers in C, I think that I will have a look through it, should be enlightening. Maybe write Lisp in HyperC when I'm done. :) UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
AABENSON@MTUS5.BITNET (01/06/91)
Hooray for Randy Hyde! I think a cease-fire would be good, also. Besides, that discussion's been getting pretty boring, anyway, and all it seems to do is get people upset.
gwyn@smoke.brl.mil (Doug Gwyn) (01/11/91)
In article <325@generic.UUCP> ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes: >Assembly language on the 65816 edges out the 8088 at almost half the clock >rate? For many typical applications, yes. It varies with the application. >I may not have majored in computer science, but doesn't both a compiler and >an assembler generate machine language? Eventually, of course. >Logically both generate the same code for the same problem solution. No, in fact compiled code is practically always different from what a human writing in assembler would have used for the same problem. >Therefore a given instruction that is good for Assmebler should also be good >for Compiler. No, because as indicated previously a human programming in assembler is in a position to exploit even the most baroque and weird instruction set. A compiler, on the other hand, is an uncreative automaton that applied preset rules to translate an unlimited variety of source code into machine code. The code generation process generally does not attempt to exploit weird instructions that are not of mnuch use in supporting general high-level language programs. >Needless to say, I know little about compiler design, but I have hand compiled >C code on the 65816 and much of the syntax is directly translatable to >assembly on a line for line basis (derefencing handles is an exception). But not for general compilation, it isn't. Again, a human can recognize efficient ways to translate a specific algorithm into machine instructions that an automatic translation system would find infeasible. >Which specific instructions are required in a computer achitecture to make >easy for an HLL compiler? It is not so much a matter of specific opcodes as it is of a suitable architecture. The best machine support for high-level languages would include a highly structured regular instruction set, universally applicable addressing modes, a uniform set of fast general-purpose registers, both positive and negative offset indexed adressing, indirect addressing, frame-oriented function linkage, and so forth. The 65816 is woefully deficient in most of these; those that it provides some support for in general have incomplete, restrictive support, making the compiler have to find some more general (and thus less efficient) solution to its needs.
gwyn@smoke.brl.mil (Doug Gwyn) (01/11/91)
In article <1990Dec31.233636.24004@dartvax.dartmouth.edu> anarch@eleazar.dartmouth.edu (The Anarch) writes: >Still, you are right to say that C is not to difficult to translate >structurally. However, what's going to kill you, as far as code efficiency >goes, are the predefined functions that C gives you to make your job easier, >like the I/O and mathematical functions. These get translated into code that >is massive and ugly next to what you could do with assembly. This is simply not true. If you in fact need the full support of buffered stream I/O, C's standard I/O facilities (at least when properly implemented) are a reasonably efficient and clean solution. As to math functions, practically always they are implemented as function calls, and the functions to perform them are implemented efficiently, too. The real overhead penalty is in the more "routine", direct programming language support. If you inspect the code generated by available IIGS C compilers, you should see that it is much less efficient in typical cases that a specially hand-tailored assembly-language implementation would be. This is primarily due to the poor match between the 65816 architecture and what a compiler really needs for effective run-time support. >To see the effect of using these functions, a good experiment is to get out >your favorite C compiler, write up the famous "Hello world" program and >compile to an executable. How big a file do you end up with? Now fire up >the mini-assembler and put together a program that accomplishes the same >thing. I would be shocked if it took you more than two dozen bytes, data >included. printf(), though, is a *big* function! C was not designed for the production of trivial programs. If you investigate a typical real application, you'll find that most printf() features are exploited; thus it is not overkill for typical applications.
gwyn@smoke.brl.mil (Doug Gwyn) (01/11/91)
In article <10872@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >For "C" you have no choice but to do this. For Pascal, whose procedures and >functions have a fixed number of parameters) the subroutine can pop the >parameters rather than the caller. Actually, a variety of implementation techniques are available for C function linkage. Apart from variadic functions, which require that a ",...)" form of declaration be in scope so that the compiler knows to generate different, less efficient linkage, C functions also have fixed number and type of arguments. The only real problem with "callee pops" lies in where to return values, especially structures. That is a solvable problem.. I understand that Ken Thompson's Plan 9 C compiler uses a really slick function linkage. I've seen other good examples.