wogg0743@uxa.cso.uiuc.edu (10/20/90)
By the way, ever notice that Apple IIe programs all take up less than 128k and yet somehow manage to be every bit as useful as Mac programs that get claustrophobia in systems smaller than 2 meg? Bill Gulstad (By the way, piss off your MacFriends by saying, "What do you mean, no text mode? The things under warrentee, isn't it? Have it fixed! It's obviously defective!")
SAB121@psuvm.psu.edu (10/23/90)
In article <139800043@uxa.cso.uiuc.edu>, wogg0743@uxa.cso.uiuc.edu says: > >By the way, ever notice that Apple IIe programs all take up less than 128k >and yet somehow manage to be every bit as useful as Mac programs that >get claustrophobia in systems smaller than 2 meg? > Yeah, I have noticed this. I thik maybe it's because the people who programmed on the ][ series grew up with 16K-64K usable for the program. Therefore, they were forced to write tight, efficient code. Plus, they weren't constrained by having to use the stupid "DeskTop Environment" that is the only thing the stupid Mac can use. Let's face it, I like the desktop on my GS, but text is the only way to go for some things, especially if they require speed. Graphics are nice, but there is such a thing as too much of a good thing. The programmers out there now (yes, even some of the people that program for my favorite, the GS) are starting to get pampered by the luxuries of having 19 bilion megabytes of memory. They seem to think that "oh well, maybe most people can't use it now, but pretty soon they'll all have that much memory!" As a side note, a former computer teacher of mine told me once (and this from an ardent IBM and Mac user) that the only machine to learn to program on is the ][ because once you've learned to program tight you usually keep it tight. >Bill Gulstad > > >(By the way, piss off your MacFriends by saying, "What do you mean, no text >mode? The things under warrentee, isn't it? Have it fixed! It's obviously >defective!") > > ------------------------------------------------------------------------- | Salvatore A. Buttice | Bitnet: SAB121@PSUVM \_ Preferred | | RD#1 Box 488 | InterNet: sab121@psuvm.psu.edu / (It's Free!) | | Espyville, PA 16424 | Cleveland FreeNet: aj670 \_ If the above does | | Apple II ForEver!! | America Online: Sal15 / not work for you! |
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (10/25/90)
I agree. Apple II code always has been tight and clean; there's no
other way to do it on a 6502. People who start to program on 68000's or
8086's find that they have all this memory and all these registers, and
they start using it all without thinking about it. On a system like the
Apple II where resources (time, memory, registers) are short, you have
to think about it.
-----------------
Jeffrey Hutzelman
America Online: JeffreyH11
Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu,
jh4o@cmuccvma
>> Apple // Forever!!! <<bchurch@oucsace.cs.OHIOU.EDU (Bob Church) (10/26/90)
In article <sb9lRJO00awBI61I15@andrew.cmu.edu> jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) writes: >I agree. Apple II code always has been tight and clean; there's no >other way to do it on a 6502. >Jeffrey Hutzelman This training could be extremely handy. Given a machine that has a huge amount of memory and registers it's easy to get sloppy. It would be interesting to see the results of two programers on such a machine, one who has learned on the overpowered ( I know, contradiction in terms :-) ) machine and one who has learned on the //, when it comes time to program for multitasking, thus giving you many small computers.
MQUINN%UTCVM@PUCC.PRINCETON.EDU (10/26/90)
On Thu, 25 Oct 90 16:48:21 GMT Jeffrey T. Hutzelman said: >I agree. Apple II code always has been tight and clean; there's no >other way to do it on a 6502. People who start to program on 68000's or >8086's find that they have all this memory and all these registers, and >they start using it all without thinking about it. On a system like the >Apple II where resources (time, memory, registers) are short, you have >to think about it. I agree whole heartedly with this, except the part about the registers. Everytime I write a ML program, I always wish I had a couple more registers because without them, I have to write more code that copies the register into a memory location, then later, more code to reload the register from that same memory location, where as, if I had those few more registers I was wishing for, I wouldn't have needed that extra load and store code and that extra memory to hold the register value. This also makes the program run a little bit slower. But I'm nit-picking, so I'll shut up now :) >----------------- >Jeffrey Hutzelman >America Online: JeffreyH11 >Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu, > jh4o@cmuccvma > >>> Apple // Forever!!! << ____________________________________________________________________ | | | | This is your brain... | BITNET-- mquinn@utcvm | | This is your brain on drugs... | pro-line: | | This is your brain on whole wheat.| mquinn@pro-gsplus.cts.com | |____________________________________|_______________________________|
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/27/90)
MQUINN%UTCVM@PUCC.PRINCETON.EDU writes: >Everytime I write a ML program, I always wish I had a couple more registers >because without them, I have to write more code that copies the register into >a memory location, then later, more code to reload the register from that >same memory location, where as, if I had those few more registers I was >wishing for, I wouldn't have needed that extra load and store code and that >extra memory to hold the register value. This is the main complaint that most people have about 65xx programming. A humble suggestion: stop thinking of the registers as your local variables (auto's in C). The zero/direct page is your auto variable space. The accumulator and index registers are your scratch space and temporaries -- they are 'hidden' from a high level language because they are needed to synthesize high level language constructs. Memory based instructions on the 65xx exist for exactly this reason. Todd Whitesel toddpw @ tybalt.caltech.edu
MQUINN%UTCVM@PUCC.PRINCETON.EDU (10/27/90)
On Fri, 26 Oct 90 21:57:28 GMT Todd P. Whitesel said: >MQUINN%UTCVM@PUCC.PRINCETON.EDU writes: > >>Everytime I write a ML program, I always wish I had a couple more registers [a bunch of my stuff deleted] >>extra memory to hold the register value. > >This is the main complaint that most people have about 65xx programming. > >A humble suggestion: stop thinking of the registers as your local variables [a bunch of stuff deleted] >Memory based instructions on the 65xx exist for exactly this reason. Oh, I agree. I was just pointing out that having more registers doesn't necessarily make the program take up more space or make it sloppy. >Todd Whitesel >toddpw @ tybalt.caltech.edu ____________________________________________________________________ | | | | This is your brain... | BITNET-- mquinn@utcvm | | This is your brain on drugs... | pro-line: | | This is your brain on whole wheat.| mquinn@pro-gsplus.cts.com | |____________________________________|_______________________________|
unknown@ucscb.UCSC.EDU (The Unknown User) (10/27/90)
In article <9010270632.AA00108@apple.com> MQUINN%UTCVM@PUCC.PRINCETON.EDU writes: >Oh, I agree. I was just pointing out that having more registers doesn't >necessarily make the program take up more space or make it sloppy. But having more registers takes up more bits of an instruction if you want instructions to be general and use any register.. (I should know, my partner & I just finished the instruction set for the computer we're building partially in hardware, and partially simulating in software) -- / Apple II(GS) Forever! unknown@ucscb.ucsc.edu \ \"If cartoons were meant for adults, they'd be on in prime time."-Lisa Simpson/
MQUINN%UTCVM@PUCC.PRINCETON.EDU (10/28/90)
On Sat, 27 Oct 90 07:24:26 GMT The Unknown User said: > But having more registers takes up more bits of an instruction >if you want instructions to be general and use any register.. (I should I don't think I follow. I don't deny this, I just don't understand it and it sounds interesting. > >-- >/ Apple II(GS) Forever! unknown@ucscb.ucsc.edu \ >\"If cartoons were meant for adults, they'd be on in prime time."-Lisa Simpson/ ____________________________________________________________________ |CENSORED CENSORED CENSORED | | |ED CENSORED CENSORED CENSORED CEN| BITNET-- mquinn@utcvm | |ENSORED CENSORED CENSORED CENSOR| pro-line: | |ORED CENSORED CENSORED CENSORED C| mquinn@pro-gsplus.cts.com | |____________________________________|_______________________________|
gwyn@smoke.brl.mil (Doug Gwyn) (10/28/90)
In article <9010271753.AA23864@apple.com> MQUINN%UTCVM@PUCC.PRINCETON.EDU writes: >On Sat, 27 Oct 90 07:24:26 GMT The Unknown User said: >> But having more registers takes up more bits of an instruction >>if you want instructions to be general and use any register.. (I should >I don't think I follow. I don't deny this, I just don't understand it and it >sounds interesting. The idea is quite simple. A machine instruction must specify what is to be done, to what the action will be applied, what input is used for the operation, and a manner of doing the action. All this is encoded in the instruction "opcode". When it is possible to infer some of this information, then no bits are needed in the opcode for that part of the specification. Otherwise, some bits must be provided to distinguish among the possibilities (for example, to select specific source and destination registers). One should note, however, that when fewer alternatives exist in the instructions, in general it will take more instructions to accomplish a given algorithm. The trade-offs are not simple to evaluate.
MQUINN%UTCVM@PUCC.PRINCETON.EDU (10/29/90)
On Sat, 27 Oct 90 21:28:58 GMT Doug Gwyn said: >The idea is quite simple. A machine instruction must specify what is to [stuff deleted to save space] >destination registers). I always wondered how that worked. I'll probably end up losing sleep tonight messing around with the 816 instruction set now that I have a little bit of an idea on how that works. :) Thanks for the info. >One should note, however, that when fewer alternatives exist in the >instructions, in general it will take more instructions to accomplish >a given algorithm. The trade-offs are not simple to evaluate. Yeah, that's what I thought, but how can having more bits per instruction slow down, increase size, or make a program sloppy? I think I can see how it might slow it down (if it does), but I'd think that it would still be faster and more efficient than the extra instructions to accomplish that task (as with that particular case I was originally talking about with having more registers). ____________________________________________________________________ |CENSORED CENSORED CENSORED C | | |ED CENSORED CENSORED CENSORED CEN| BITNET-- mquinn@utcvm | |ENSORED CENSORED CENSORED CENSOR| pro-line: | |ORED CEBSORED CENSORED CENSORED C| mquinn@pro-gsplus.cts.com | |____________________________________|_______________________________|