barnard@boulder.Colorado.EDU (BARNARD DALE AARON) (03/23/90)
Out of curiousity, what languages are used in the software that we see in the stores for Apple IIe? For example, in what language is Appleworks programmed? How about games? Thanx
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/23/90)
In article <18753@boulder.Colorado.EDU> barnard@snoopy.Colorado.EDU (BARNARD DALE AARON) writes: >Out of curiousity, what languages are used in the software that we see in the >stores for Apple IIe? For example, in what language is Appleworks programmed? >How about games? I've seen everything from 6502 assembler through BASIC to Pascal and C. Given currently available compilers for the 8-bit Apples, really time- critical programs such as arcade games are most likely coded in assembler. Wizardry was done in Apple (UCSD) Pascal. Sierra On-Line's recent games, like Infocom's, are coded in a special game programming language that is interpreted by a fast run-time support system coded in assembler. The Claris folks will probably tell you about AppleWorks; similar products on other systems are often coded in a mixture of C and assembler (mostly C); unfortunately there hasn't been a fully satisfactory C compiler for the 8-bit Apples, which has been one factor in retarding software availability for them. (Their puny RAM and disk capacity is a larger factor, though.)
muller@Alliant.COM (Jim Muller) (03/24/90)
In article <12410@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: | In article <18753@boulder.Colorado.EDU> barnard@snoopy.Colorado.EDU (BARNARD DALE AARON) writes: || what languages are used in the software...in the stores for Apple IIe? | Wizardry was done in Apple (UCSD) Pascal. So was GATO. (I'd kinda' like to know how they did some of that stuff.) -- - Jim Muller
MMPR004@ECNCDC.BITNET (Scott Hutinger) (03/24/90)
> BARNARD DALE AARON <snoopy!barnard@BOULDER.COLORADO.EDU> writes: >Out of curiousity, what languages are used in the software that we see in the >stores for Apple IIe? For example, in what language is Appleworks programmed? >How about games? This is not the answer you want, but the thoughts of Higher Education. Most use assembler of some type..which leads me to a statement a professor once told me when I told him about wanting to take some graduate classes a couple years ago... "Nobody writes in assembler anymore..." Hmmm, whats his problem? scott hutinger mmpr004@ecncdc.bitnet
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/24/90)
In article <9003232001.AA00592@apple.com> MMPR004@ECNCDC.BITNET (Scott Hutinger) writes: >..which leads me to a statement a professor once told me when I told him >about wanting to take some graduate classes a couple years ago... >"Nobody writes in assembler anymore..." >Hmmm, whats his problem? Perhaps he was trying to do his job and educate you.. There are so many drawbacks to coding in assembler (as compared to a higher-level language, C in particular) that there are only two reasons you should do it: (1) For certain operations it may be necessary to work at that level. For example, the provider of the run-time support library for the C language must use assembler to implement certain low- level operations to support the language. (That doesn't mean the whole system library has to be coded in assembler, just the parts that cannot be written in C.) Note that this level includes less than is commonly supposed. In particular, device drivers can be written in C (and normally are, for UNIX implementations). Even on the Apple I've written C code that efficiently diddles memory-mapped I/O registers, for example to control the serial port UART without the overhead of Apple slot I/O hooks, toolboxes, etc. (By the way, this is not recommended practice for most commercial code, because it risks the program breaking when Apple revises their hardware. This is however independent of the programming language used.) (2) There may be cases where it is essential to squeeze as much speed as possible out of a given computer. This can usually be done with the higher-level language, but occasionally it may happen that assembler really is necessary. The cost of using C is usually no worse than a 1.3 slowdown over hand-tuned assembler (assuming a good architecture, an optimizing compiler, and an aware programmer), but on horrible architectures like the 65* family the cost is normally worse than that, typically a factor of 2 or more. Usually this is unimportant for typical applications, certainly not offsetting the advantages of developing in a higher- level language, but in some cases (e.g. some arcade games) it is important. Even so, most likely only a small portion of the application constitutes the bottleneck and so only a small portion needs special attention (such as recoding in assembler).
stephens@latcs1.oz.au (Philip J Stephens) (03/24/90)
In article <12423@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > There are so many drawbacks to coding in assembler (as compared to a > higher-level language, C in particular) that there are only two reasons > you should do it: > > (1) For certain operations it may be necessary to work at that > level. > > (2) There may be cases where it is essential to squeeze as much > speed as possible out of a given computer. (3) Coding in assembler _can_ be fun. Come on guys, maybe you don't ever want to write assembly code for a VAX or a Pyramid; but an Apple ][ machine is different. It's no big deal to develop programs in 6502 assembler on an Apple ][+, for instance; particularly if you want to write an arcade game running at 1 MHz. A lot of people will still try and write most of an arcade game in AppleSoft or Pascal for instance, and only code the low-level graphics routines in assembler. But it's overkill! Once you've coded the graphics subroutines, the rest of an arcade game is typically only a few hundred instructions at most. Big deal! I enjoy fiddling around with machine code, if only because it's more of a challenge and more satisfying. If I'm lazy, I'll write it in AppleSoft or Turbo Pascal. If I'm feeling adventurous, I'll use assembly language. People who say you should never write in assembly unless you have no other choice are quite often reciting what they've learnt in Computer Science classes. (I'm not refering to the poster here!!! This is from past experience). Those Apple hackers that have been writing 6502 code since year 10 onwards would tend to beg to differ. I am one of those people. As far as I'm concerned, 6502 assembly is just another language. A low-level language, yes, but a language nevertheless. When you have been using it as long as I have, the "difficulty" in programming 6502 code pretty much disappears in a puff of smoke. Along with all of the so-called disadvantages. Obviously there is a limit on the _size_ of assembly you'd want to write before it became too unwieldy, but the same applies for high-level languages. Any program above 10,000 lines of code in either language is just too much. In short, assembly has it's place. It's just that with faster and more powerful machines appearing, there is less _need_ to use it. I still have my Apple ][+. It stills runs at 1 MHz. Hence I still write in assembly. It's as simple as that. </\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\></\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\> < Philip J. Stephens >< "Many views yield the truth." > < Hons. student, Computer Science >< "Therefore, be not alone." > < La Trobe University, Melbourne >< - Prime Song of the viggies > <\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>
cwilson@NISC.SRI.COM (Chan Wilson) (03/25/90)
In article <7494@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: >In article <12423@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >> There are so many drawbacks to coding in assembler (as compared to a >> higher-level language, C in particular) that there are only two reasons >> you should do it: Blah. Show me a C compiler for the GS that is as simple to use and as stable as Merlin 16+, and I'll consider moving to C. >> >> (1) For certain operations it may be necessary to work at that >> level. >> >> (2) There may be cases where it is essential to squeeze as much >> speed as possible out of a given computer. > > (3) Coding in assembler _can_ be fun. > > Come on guys, maybe you don't ever want to write assembly code for a VAX >or a Pyramid; but an Apple ][ machine is different. It's no big deal to >develop programs in 6502 assembler on an Apple ][+, for instance; particularly >if you want to write an arcade game running at 1 MHz. (4) Coding in assembly is _always_ faster. I'm not saying it's easier, mind you, but it's faster. Although I haven't mucked with any high level languages for a couple years now, when I was taking/teaching a high school pascal course the compiler was unbelievably slow. And the resulting code wasn't all that swift. > People who say you should never write in assembly unless you have no other >choice are quite often reciting what they've learnt in Computer Science >classes. (I'm not refering to the poster here!!! This is from past >experience). Same here. > Those Apple hackers that have been writing 6502 code since year >10 onwards would tend to beg to differ. I am one of those people. > As far as I'm concerned, 6502 assembly is just another language. >A low-level language, yes, but a language nevertheless. When you have been >using it as long as I have, the "difficulty" in programming 6502 code pretty >much disappears in a puff of smoke. Along with all of the so-called >disadvantages. Heck yes. Get enough macro libraries, and you can do anything. :) Besides, with the state of today's high-level compilers for the GS (C, pascal), I'll stick with assembler. --Chan ................ Chan Wilson -- cwilson@nisc.sri.com <!> I don't speak for SRI. Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu "And now, the penguin on top of the television set will explode." ................
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/25/90)
In article <7494@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: > As far as I'm concerned, 6502 assembly is just another language. >A low-level language, yes, but a language nevertheless. When you have been >using it as long as I have, the "difficulty" in programming 6502 code pretty >much disappears in a puff of smoke. Along with all of the so-called >disadvantages. I didn't spell out the disadvantages, but for my purposes one of the most important ones is that assembly code is vastly less portable than well- designed C code. If you only have one type of computer AND if you don't expect to have to use your application with another type for many years to come, then portability will not be a significant issue for you. But many of us deal with lots of computer types and wish to obtain maximum leverage for the time we invest in programming. For us, portability is quite important, with the consequence that we don't spend any more time writing assembly code than is forced upon us by circumstances such as those I outlined in my previous posting on this topic.
pnakada@oracle.com (Paul Nakada) (03/25/90)
In article <9003232001.AA00592@apple.com> MMPR004@ECNCDC.BITNET (Scott Hutinger) writes: >> BARNARD DALE AARON <snoopy!barnard@BOULDER.COLORADO.EDU> writes: >>Out of curiousity, what languages are used in the software that we see in the >>stores for Apple IIe? For example, in what language is Appleworks programmed? >>How about games? > This is not the answer you want, but the thoughts of Higher Education. >Most use assembler of some type..which leads me to a statement a professor True, but I thought I'd add that most assembly programming (non speed intensive) is done with large libraries of macros allowing for more complex memory manipulations and easier access to 16 bit operations. -Paul Nakada pnakada@oracle.com
spike@world.std.com (Joe Ilacqua) (03/26/90)
au> <14615@fs2.NISC.SRI.COM>
Sender:
Followup-To:
Reply-To: spike@world.std.com
Distribution:
Organization: Software Tool & Die
Keywords:
In article <14615@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes:
< (4) Coding in assembly is _always_ faster.
<
<I'm not saying it's easier, mind you, but it's faster. Although I haven't
<mucked with any high level languages for a couple years now, when I was
<taking/teaching a high school pascal course the compiler was unbelievably
<slow. And the resulting code wasn't all that swift.
Now if we are talking 'assembly on Apple{//,][}s' then I might
agree with you. But in general modern compilers are fast, and some
even product faster code. A compiler is able to view to hole program
a once and can often make much more far reaching optimizations than
most programers.
->Spike
--
"The World" - Public Access Unix - +1 617-739-9753 24hrs {3,12,24}00bpsstephens@latcs1.oz.au (Philip J Stephens) (03/26/90)
In article <1990Mar25.210033.14719@world.std.com>, spike@world.std.com (Joe Ilacqua) writes: > In article <14615@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes: > < (4) Coding in assembly is _always_ faster. > > Now if we are talking 'assembly on Apple{//,][}s' then I might > agree with you. But in general modern compilers are fast, and some > even product faster code. A compiler is able to view to hole program > a once and can often make much more far reaching optimizations than > most programers. This is rather doubtful. Most compiler optimisation concentrates on assigning registers for calculations, and removing all of the unnecessary and duplicate assembly instructions. Overall global optimisation is _extremely_ difficult to achieve, and compilers that perform such optimisation tend to be somewhat buggy. Compilers don't view the whole program at once. Optimisation tends to be local rather than global, since in order to achieve higher levels of optimisation the compiler must _know_ what the program is doing. It seems to me that most programmers ought to be write better code than a compiler; generally assembly programmers tend to write very wieldy code simply because it takes less effort! Look at any 6502 program in Nibble and you'll see what I mean. Modern compilers on an Apple cannot hope to produce faster code than pure assembly. Compilers on minicomputers is a different story, since the machine is damn fast anyhow, and nobody wants to write in assembly language on a UNIX machine (let's face it, C is bad enough :-) I doubt whether a high-level language compiler can be written for an Apple that generates code that is faster than assembly language. </\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\></\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\> < Philip J. Stephens >< "Many views yield the truth." > < Hons. student, Computer Science >< "Therefore, be not alone." > < La Trobe University, Melbourne >< - Prime Song of the viggies > <\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/27/90)
In article <7509@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: > Compilers don't view the whole program at once. Neither do assemblers. > It seems to me that most programmers ought to be write better code than a >compiler; ... Believe it or not, but the issue of relative performance of hand-coded assembler vs. higher-level language has been the subject of many studies. Depending on the nature of the problem and on the higher-level language involved, compiled code can run anywhere from somewhat faster (yes!) to several times slower. Because C was developed specifically for systems programming, a skilled program can write C code that is comparable in run-time efficiency to hand-coded assembler, for the majority of such applications. This does assume that the underlying CPU architecture offers reasonable support for such higher-level languages; the VAX, MC68000, NS32000, SPARC, etc. all do, whereas the 65816 doesn't really. Thus compiled code on an Apple IIGS typically suffers worse in comparison with assembler than on typical systems. However, keep in mind that time spent in making non-bottleneck sections of code run faster is time wasted. Even if you're after speed, assembler should be used for only a small fraction of an application.
rhood@pro-gsplus.cts.com (Robert Hood) (03/28/90)
In-Reply-To: message from stephens@latcs1.oz.au Re: programming in 6502 assembly - reasons to do so Don't forget reason (4): because you want a lot of code to fit into a small space. In my experience, code produced from a compiler is inflated from what it would've been if written directly. I'm almost fluent in 6502, and I enjoy programming applications in it. I haven't quite taken the plunge and abandoned the BASIC interface yet, but I hope to soon.... Robert Hood - programmer ProLine address: pro-gsplus!rhood