DEFFER@CGEUGE51.BITNET (07/13/88)
Warning: No one is targeted here but better put your flame shields on to avoid being splashed. In reply to Todd South <tsouth%pro-pac.cts.com@BRL.ARPA> Apple's market strategy is simple: they want to reduce costs by supporting one unique serie of compatible computers, the Mac line. You may ask then, why did they design the GS ? This computer is and shall stay targeted at hobbyists, like it's dad, the Apple II. The GS was designed because someone to whom Apple owed a lot, wanted to give Apple's first fans a beautiful toy. The GS is almost 2 years old now and if the GS meant business, well take a look at what follows: Quoting Keith Rollin <claris!apple!keith@AMES.ARC.NASA.GOV> >That's the intention, Scott. We're working on it as fast as we can. These >samples should be ready in a couple of months. There are only two of us right >now working on about 2 dozen program simultaneously. This is in addition to >giving support to developers by answering their questions. If the GS meant businees, delays would be given in weeks, not in months. If the GS meant business, these demos would have been done when the GS started shipping 2 years ago. >Tech support for the Apple line should be explained and appologized for. Up >until a few months ago, Apple virtually didn't have an Apple II tech support >department. If the GS meant business, we GS owners wouldn't accept any apologies. If the GS meant business, Apple II tech support would not have been virtual vacuum until now, 2 years after starting shipping the GS. > However, that was not a marketing decision!!! It was sheer bad >luck. 3 peole left the group around the same time, reducing the number of >people left to answer all the questions we get to 3. If the GS meant business, we GS owners wouldn't depend on luck to get support. If the GS meant business, there would be more than 3 or 6 people answering questions. How many GS have been sold in total ? (Apple employs 1'200 people, see last week's Datamation). >In March of this year, >4 new people were hired (including yours truly). Since then, we have been able >to keep up with our e-mail questions, and have started writing new technotes, >revising all of the old ones, and creating "Living technotes", the demos that >have been alluded to. So as that guy said in 2010, "Something wonderful is >going to happen"!!! Hang in there. If the GS meant business, it wouldn't be wonderful, just plain comittment. >I hope that is enough to whet your appetite. Now I just hope that we ship this >thing, now that I've promised it to everyone. BTW, I don't know how the >distribution is going to be handled on this. The original idea was simply to >mail it to developers. However, I want it sent to APDA as well. I don't know >if electronic distribution is going to be done, as there is a LOT of source. >Up and downloading would reduce this net to tears! (the programs were actually >shorter, but some people in SW Engineering insisted that we comment the >suckers...imagine! :-) If the GS meant business, Apple would send these notes and demos by first class air mail to every one who asks for them FOR FREE (they can afford it). I am a member of APDA but please, do send them on this net, lots of GS owners aren't. Why can't you for once make a nice move and provide something without being asked ? Keith, please don't give excuses for decisions taken by Apple before you started working there. It makes no sense. About GS Works, well my opinion is that Apple does not want to develop software, and definitely doesn't want to increase the size of it's GS departement because they don't want to spend money on the GS line. If Apple bought Styleware, ooops i mean if Claris bought Styleware, I believe it's because they want to get the credit. This tactic could have worked well if they bought Styleware a couple of months ago before they published that ad in apple 2 magazines. But after all, do all the GS owners read magazines ? I don't think so. What really pisses me off, is that Styleware was a symbol for the GS, they were committed to it, like AE, MDI, Orange and such companies. Imagine Apple buying AE. I only wish someone has developed a GS SuperWorks Claris back to the lockers. ----- Eric DEFFERARD BITNET DEFFER@CGEUGE51 UUCP mcvax!cernvax!cui!deffer
maddie@crash.cts.com (Tom Schenck) (07/18/88)
[ Sorry, but that message got me fired up ] Since the //gs was introduced, the only thing about it that has impressed me was the fact that it has 15 independant voices for generating very nice sound. I have never really like the //gs OR the Mac (ANY of them) for any serious programming work. Why? Because everything you do, even if you write it in straight machine code, goes through an intepreter. The OS on the //gs and the mac has just too much overhead, and is to high-level for me to ever consider it as a serious programming machine. Right now, the machine of choice for my programming is an IBM PC clone. I would use an Apple //e (with 1 meg of RAM of course), but I don't have the money for the rediculously high prices of the Apple //e (even used). The PC clone was already here, so I used it. The only thing I really want to say of much importance, is that if Apple was serious about maintaining the Apple // line, they wouldn't have made the //gs so much like a Mac. --
marc@lakesys.UUCP (Marc Rassbach) (07/19/88)
Tom,
What do you mean when you say "all code goes through an interperter?"
Do you mean the 'standard user interface' ie the 'toolbox' or the microcode on
the microprocessor?
If you mean the 'toolbox', I hate to tell you this, but the newer IBM's
are supporting such a bizzare concept. IBM is now pushing an operating
system called OS/2, and one of the main features of OS/2 is the graphics
interface to the software. (To use the words of an Apple rep. I know, IBM
now stands for I Built a Mac! (in ref. to the announcement of OS/2))
Don't get me wrong, an IBM is great for running a bbs, storing lotsa data
for processing in a Dbase, etc. But no IBMer can get the same level of
desk-top publishing for the same $$$ as a Mac owner. And I have yet to see
IBM programs (the majority) as user freindly as a Mac. (my personal
preferance: User hostile software that one has to subdue. Makes one enjoy
a good program :-)
Marc Rassbach
The ideas expressed are my own, and if you don't like them, you are in the
majority.
"Ask me no questions, and I shall tell you no lies. FNORD."maddie@crash.cts.com (Tom Schenck) (07/22/88)
In article <834@lakesys.UUCP> marc@lakesys.UUCP (Marc Rassbach) writes: >Tom, > > What do you mean when you say "all code goes through an interperter?" >Do you mean the 'standard user interface' ie the 'toolbox' or the microcode on >the microprocessor? I mean that the 6800 family is not a microprocessor, but, in fact, a small equivilent of a computer. It checks ever instruction that comes in against a set list, and then against a user list. If a problem is encountered, it jumps to an error handling section, and generates a few interrupts. > > If you mean the 'toolbox', I hate to tell you this, but the newer IBM's I don't mean the Toolbox, but the toolbox is cause for a lot of overhead. A toolbox, however, is a great way to provide compatability between models. > > Don't get me wrong, an IBM is great for running a bbs, storing lotsa data An IBM is great for doing this, yes. But if it starts using the interpreting OS, I'm going back to my Apple ][, and going to build a 25Mhz accelearator! >for processing in a Dbase, etc. But no IBMer can get the same level of >desk-top publishing for the same $$$ as a Mac owner. And I have yet to see >IBM programs (the majority) as user freindly as a Mac. (my personal >preferance: User hostile software that one has to subdue. Makes one enjoy >a good program :-) I definatly agree with you there, but I also am quite good at subduing user- hostile programs. I really haven't had any problems with any programs, even if it is hard to use, I just complain, not give up. I also enjoy using the Mac, but it hurts me as a programmer to see such a fast machine slowed down so much so a phenominal amount of overhead. > >Marc Rassbach Tom Schenck, Member 52nd Development Team >The ideas expressed are my own, and if you don't like them, you are in the >majority. The idea expressed are those of the company I am in, which is owned by me, so it doesn't really matter. -- UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!maddie ARPA: crash!pnet01!maddie@nosc.mil INET: maddie@pnet01.CTS.COM Disclaimer : The only company who's thoughts are my own is owned by me. Tom Schenck, member 52nd Street Development Team.
neighbor@csd4.milw.wisc.edu (Jeffrey Alan Ding) (07/22/88)
In article <3228@crash.cts.com> maddie@crash.CTS.COM (Tom Schenck) writes: >In article <834@lakesys.UUCP> marc@lakesys.UUCP (Marc Rassbach) writes: >>Tom, >> >> What do you mean when you say "all code goes through an interperter?" >>Do you mean the 'standard user interface' ie the 'toolbox' or the microcode on >>the microprocessor? > > I mean that the 6800 family is not a microprocessor, but, in fact, a small 6800? What computer uses the 6800 family? The Apple ][ series computers All use the 6500 family of microprocessors. I don't know about the 6800 series but the 6500 series has *NO* bullshi*t as to what your talking about. I have the *HARDWARE* manual on the 6500 MOS series microprocessors. It talks about the 6500,6501,6502,6503,6504, and 6505 microprocessors. It even talks about the Motorola 6800 chip, compares them, and points out the strengths of the MOS series. (Pull out my trusty Apple ][ reference manual) Here it says: The 6502 Microprocessor Model: MCS6502/SY6502 Manufactured: MOS Technology, Inc. Synertek Rockwell (Take a look at my hardware manual) Here it says: MCS6502 Microcomputer family hardware manual MOS technology, inc. Well now these two microprocessors are the same. Now does the manual speak of any PRE-processing? > equivilent of a computer. It checks ever instruction that comes in against > a set list, and then against a user list. If a problem is encountered, it > jumps to an error handling section, and generates a few interrupts. I don't see anything meantioned in the manual about what you just said. This IS what it does: Each instruction is loaded into the micro, If it doesnt match up to a real instruction, the micro sh*ts and the computer bombs. Anything can happen when the computer bombs. Where the H*LL to you get off saying it generates interrupts? > I don't mean the Toolbox, but the toolbox is cause for a lot of overhead. > A toolbox, however, is a great way to provide compatability between models. All the toolbox does it provide the user with machine language programs to perform miscellaneous tasks. If the toolbox wasn't there, the user would have to write the same programs anyway. *NO* overhead is lost. The only reason you lose perforance is because the toolbox has *generalized* routines. If the user writes is own, he can make them specific and more efficient. > An IBM is great for doing this, yes. But if it starts using the interpreting > OS, I'm going back to my Apple ][, and going to build a 25Mhz accelearator! Yes the newer IBM's are going the way of the MAC, but this does *NOT* mean the OS is interpreted! Machine language is the LOWEST form of programming. The ONLY other interpretation is the decoding of the instructions by HARDWARE. This is NOT interpreted! It is my guess you have never owned an Apple ][ computer. And you can go ahead and TRY to buile a 25Mhz accelerator! It will NEVER work! Besides, How can you build anything when you don't even know what microprocessor the computer used! :-) >Tom Schenck, Member 52nd Development Team neighbor@csd4.milw.wisc.edu _______________________________________________________________________________ | arpanet: neighbor@csd4.milw.wisc.edu | | UUCP: ihnp4!uwmcsd1!csd4!neighbor | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
maddie@crash.cts.com (Tom Schenck) (07/23/88)
In article <6254@uwmcsd1.UUCP> neighbor@csd4.milw.wisc.edu (Jeffrey Alan Ding) writes: >In article <3228@crash.cts.com> maddie@crash.CTS.COM (Tom Schenck) writes: >>In article <834@lakesys.UUCP> marc@lakesys.UUCP (Marc Rassbach) writes: >>>Tom, >>> >>> What do you mean when you say "all code goes through an interperter?" >>>Do you mean the 'standard user interface' ie the 'toolbox' or the microcode on >>>the microprocessor? >> >> I mean that the 6800 family is not a microprocessor, but, in fact, a small > >6800? What computer uses the 6800 family? The Apple ][ series computers >All use the 6500 family of microprocessors. I don't know about the 6800 >series but the 6500 series has *NO* bullshi*t as to what your talking about. > THAT was a typo. (Yes, good flame on it too.. sheesh). What I was SPEAKING of is the 68000 (extra 0 at the end). And the //gs is built to simulate the 68000 as close as it can. >Well now these two microprocessors are the same. Now does the manual speak >of any PRE-processing? No, the manual doesn't speak of any pre-processing, because you're looking in the wrong manual. Look in the 68000 manual. > >> equivilent of a computer. It checks ever instruction that comes in against >> a set list, and then against a user list. If a problem is encountered, it >> jumps to an error handling section, and generates a few interrupts. > >I don't see anything meantioned in the manual about what you just said. >This IS what it does: Each instruction is loaded into the micro, If it doesnt >match up to a real instruction, the micro sh*ts and the computer bombs. >Anything can happen when the computer bombs. Where the H*LL to you get off >saying it generates interrupts? Well, ever seen the message "Sorry a System error has occured"? > >> I don't mean the Toolbox, but the toolbox is cause for a lot of overhead. >> A toolbox, however, is a great way to provide compatability between models. > >All the toolbox does it provide the user with machine language programs to >perform miscellaneous tasks. If the toolbox wasn't there, the user would have >to write the same programs anyway. *NO* overhead is lost. The only reason >you lose perforance is because the toolbox has *generalized* routines. If >the user writes is own, he can make them specific and more efficient. When you call the toolbox, or when the computer itself calls the toolbox (and it does. When the mouse moves, when any interrupt occurs, it calls the toolbox (including a screen refresh interrupt) and does something with it, and makes the computer wait) it takes time, because it has to determine what you want to do before it can act. Yes, you can write your own routines. I always do. I even have my own (substatially faster) "HOME" routine for the Apple ][ series. I never rely on the ROM routines, unless I don't have TIME to do it myself, in which case I provide a way for me to include my own routine. > >> An IBM is great for doing this, yes. But if it starts using the interpreting >> OS, I'm going back to my Apple ][, and going to build a 25Mhz accelearator! > >Yes the newer IBM's are going the way of the MAC, but this does *NOT* mean >the OS is interpreted! Machine language is the LOWEST form of programming. >The ONLY other interpretation is the decoding of the instructions by >HARDWARE. This is NOT interpreted! It is my guess you have never owned >an Apple ][ computer. And you can go ahead and TRY to buile a 25Mhz >accelerator! It will NEVER work! Besides, How can you build anything >when you don't even know what microprocessor the computer used! :-) > I DID say *IF* is starts. I know the IBM's aren't interpreted YET, and they may never be. But if they do, look for an Apple ][-like computer running at 25Mhz, with 1 meg (expandable to 16) of RAM, OS in ROM (with some exceptions, to provide for improvements). It will probably have to include more than one processor. Oh well... A ][e with 16 65c02's, that's an idea.. hmmm... 8-) > >>Tom Schenck, Member 52nd St Development Team > >neighbor@csd4.milw.wisc.edu > >_______________________________________________________________________________ >| arpanet: neighbor@csd4.milw.wisc.edu | >| UUCP: ihnp4!uwmcsd1!csd4!neighbor | Tom Schenck, Member 52nd St Development Team -- UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!maddie ARPA: crash!pnet01!maddie@nosc.mil INET: maddie@pnet01.CTS.COM Disclaimer : The only company who's thoughts are my own is owned by me. Tom Schenck, member 52nd Street Development Team.
whitney@think.COM (David Whitney) (07/23/88)
In article <6254@uwmcsd1.UUCP> neighbor@csd4.milw.wisc.edu (Jeffrey Alan Ding) writes: >In article <3228@crash.cts.com> maddie@crash.CTS.COM (Tom Schenck) writes: >>In article <834@lakesys.UUCP> marc@lakesys.UUCP (Marc Rassbach) writes: >>>Tom, >>> >>> What do you mean when you say "all code goes through an interperter?" >>>Do you mean the 'standard user interface' ie the 'toolbox' or the microcode on >>>the microprocessor? >> >> I mean that the 6800 family is not a microprocessor, but, in fact, a small > >6800? What computer uses the 6800 family? The Apple ][ series computers >All use the 6500 family of microprocessors. I don't know about the 6800 >series but the 6500 series has *NO* bullshi*t as to what your talking about. Well, the 68000 (and 68020 and if I guess right, the 8088 and derivatives) have real microprocessor instructions, and then something called 'traps'. Traps are undefined microprocessor instructions. It happens that the Mac sets up what is supposed to happen when specific traps occur. For example (this is hypothetical as I really don't know any trap #s), A8E0, an undefined 68000 opcode may very well start up Quickdraw. IBM machines have INT instructions, which basically do the same sort of thing. One does INT 28 to make the IBM do something interesting. Macsbug, and other Mac debuggers can have any and all toolbox calls stop the machine and pop up the debugger. This is easy, as all Macsbug has to do is replace the trap code that the 68000 would normally execute. So, in this sense, the 68000 and 8088 are kinda like interpreters - but only when it comes across an opcode which is undefined. I believe that the designer of the 65816 had this in mind when he wrote the COP instruction. One does COP #<something> to make something interesting happen. Currently, there is no support for the instruction, but who knows what the future holds? This instruction will allow 256 more opcodes and quite possibly other neat stuff (like really invoking a co-processor). BRK also now takes one parameter - who knows how to use it? David Whitney, MIT '90 Still learning about my Apple //GS {out there}!harvard!think!whitney and all of its secrets. Any and all whitney@think.com technical info appreciated. DISCLAIMER: You think they even know I'm doing this?
neighbor@csd4.milw.wisc.edu (Jeffrey Alan Ding) (07/24/88)
>>In article <3228@crash.cts.com> maddie@crash.CTS.COM (Tom Schenck) writes: >>> >>> I mean that the 6800 family is not a microprocessor, but, in fact, a small >> >>6800? What computer uses the 6800 family? The Apple ][ series computers >>All use the 6500 family of microprocessors. I don't know about the 6800 > >THAT was a typo. (Yes, good flame on it too.. sheesh). What I was SPEAKING of is the 68000 (extra 0 at the end). And the //gs is built to simulate the 68000 as close as it can. A typo? eh? Where did you learn to type? If your going to reply to a message be SURE you check what you've written so that NO ONE will misinterpret it! //gs built to similate the 68000? Since when? What part of it simulates the 68000? I think the //gs simulates a MAC. This is SOFTWARE we are talking about. You do know the difference between SOFTWARE and HARDWARE do you not? You don't build a computer to simulate a microprocessor. You make software to simulate/imitate other software. The //gs is perfectly capable of running non graphical software. And I think it does a much better job doing it too. The MAC on the other hand has nothing but graphics so that is what it uses. The //gs can live in two worlds, text and graphics. Reverting back to your original posting: >I have never really like the //gs OR the Mac (ANY of them) for any serious >programming work. Why? Because everything you do, even if you write it in >straight machine code, goes through an intepreter. The OS on the //gs and the >mac has just too much overhead, and is to high-level for me to ever consider >it as a serious programming machine. Now this is the real argument there. If machine language is too high-level for you then what do you program in?? If you can program in a language that is LOWER than machine, then tell the rest of the world and you will be a MILLIONAIR! (I don't mean binary either.) Seriously now, I really don't understand why you even care if the micro does a little pre-processing before it performs the given instruction. Every instruction uses a specific number of clock cycles, and the microprocessor is running at so many cycles per second. If that is too slow for you then don't use it! >>>Tom Schenck, Member 52nd St Development Team >> neighbor@csd4.milw.wisc.edu _______________________________________________________________________________ | arpanet: neighbor@csd4.milw.wisc.edu | | UUCP: ihnp4!uwmcsd1!csd4!neighbor | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
terranova@vms.macc.wisc.edu (07/24/88)
In article <24361@think.UUCP>, whitney@think.COM (David Whitney) writes... > >Well, the 68000 (and 68020 and if I guess right, the 8088 and >derivatives) have real microprocessor instructions, and then something >called 'traps'. Traps are undefined microprocessor instructions. It >happens that the Mac sets up what is supposed to happen when specific >traps occur. For example (this is hypothetical as I really don't know >any trap #s), A8E0, an undefined 68000 opcode may very well start up >Quickdraw. IBM machines have INT instructions, which basically do the >same sort of thing. One does INT 28 to make the IBM do something >interesting. Macsbug, and other Mac debuggers can have any and all >toolbox calls stop the machine and pop up the debugger. This is easy, >as all Macsbug has to do is replace the trap code that the 68000 would >normally execute. > >So, in this sense, the 68000 and 8088 are kinda like interpreters - >but only when it comes across an opcode which is undefined. I believe I am not familiar with the Intel processors so the following discussion regards the MC68000 microprocessor found in the Mac+/SE: There are two types of traps: A-line and F-line. They are identified by the high nibble of the opcode. These traps are used to extend the instruction set of the 68000. I forget exactly how it works but, the effect is that the the following 12 bits of the opcode is used as an offset into a jump table. (I forget if Apple's system code strips the high nibble and jumps or if the 68000 does it itself). If you want to call these two steps interpreting (1. strip the high nibble 2. jump) then be my guest. The point is that the overhead to do this is minimal. Yes, the Mac does more garbage after encountering the A-trap but before the jump but, that is easily circumvented when speed is an issue. To do what the trap dispatcher does (use the offset to get the address to jump to, check various flag bits in the opcode, etc.) would be a lot of extra work for the programmer. BTW, you will notice that all developers who use the 68000 traps use only the A-line traps. Coincidence? I think not. Motorola has explicitly stated that anyone using F-line traps will promptly be taken into the back alley and shot. (No, not really, but you get the idea.) Motorola has reserved F-line traps for their own use to extend the processors with extra little frills like the 68881 numeric co-processor and the 68851 PMMU. These co-processors are accessed through F-line traps. P.S. I am a Mac man, myself, but I would appreciate any info GS hackers/ programmers can give me regarding similarities and differences between it and the Mac (when the GS is running in the graphics/window mode). o Do programs get and handle events like the Mac? o What is the TaskMaster? I have read a little about it on the net but don't understand too well. o How are the toolbox (toolsets?) calls handled/dispatched? o Someone said that the GS tries to imitate the 68000 - how? THANKS much. > >David Whitney, MIT '90 Still learning about my Apple //GS >{out there}!harvard!think!whitney and all of its secrets. Any and all >whitney@think.com technical info appreciated. >DISCLAIMER: You think they even know I'm doing this? --------------------------------+---------------------------------------- John C. Terranova | I said it. CS, BS to be | So, flame me. terranova@vms.macc.wisc.edu | No one else. --------------------------------+---------------------------------------- Where's the orchestra? -Billy Joel, "Where's the Orchestra?"
maddie@crash.cts.com (Tom Schenck) (07/25/88)
>A typo? eh? Where did you learn to type? If your going to reply to a >message be SURE you check what you've written so that NO ONE will misinterpret >it! Sorry, next time I'll re-check the article 5 times before I send it, and have 5 or 6 friends double check it, and take a typing course in the mean-time. >the 68000? I think the //gs simulates a MAC. This is SOFTWARE we are talking >about. You do know the difference between SOFTWARE and HARDWARE do you not? Yes, I quite no the difference between hardware and software. The //gs IS built to simulate the 68000 environment as much as possible. It's not built to JUST do this, but it was designed to do this as WELL as many other things... >You don't build a computer to simulate a microprocessor. You make software >to simulate/imitate other software. The //gs is perfectly capable of running >non graphical software. And I think it does a much better job doing it too. The 68000 is in no way a graphics-only processor. You seem to have forgotten the difference between hardware and software here. And I happen to LIKE the ability of the //gs (being able to run text-only software). >The MAC on the other hand has nothing but graphics so that is what it uses. I know, and I dispise that about the Mac. The term programs I have seen are AWFUL. And a lot of utilites suffer from having to use the windowing idea. >The //gs can live in two worlds, text and graphics. And it lives in both worlds quite well. >Reverting back to your original posting: Okay, lets. > >>I have never really like the //gs OR the Mac (ANY of them) for any serious >>programming work. Why? Because everything you do, even if you write it in >>straight machine code, goes through an intepreter. The OS on the //gs and the >>mac has just too much overhead, and is to high-level for me to ever consider >>it as a serious programming machine. > >Now this is the real argument there. If machine language is too high-level >for you then what do you program in?? If you can program in a language that >is LOWER than machine, then tell the rest of the world and you will be >a MILLIONAIR! (I don't mean binary either.) (oops! I think I spot a spelling error there!) If you would like to provide me with a way to by-pass the toolbox to do operations, I'd be happy to start programming on the Mac again. I dispise having to depend on Toolbox routines to do things. I like the convinence, but I would like to be able to NOT use them if I can. > >Seriously now, I really don't understand why you even care if the micro >does a little pre-processing before it performs the given instruction. Every >instruction uses a specific number of clock cycles, and the microprocessor >is running at so many cycles per second. If that is too slow for you then >don't use it! It is too slow for me, and I don't use it. I no longer program on the Mac. An Apple //e (running at a measly 3.66 Mhz, not the snails-pace of 1.023) is about the same speed running a lot of operations I've been doing. Maybe my 68000 code is sloppy, but I doubt it. Tom Schenck, Member 52nd St Development Team -- UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!maddie ARPA: crash!pnet01!maddie@nosc.mil INET: maddie@pnet01.CTS.COM Disclaimer : The only company who's thoughts are my own is owned by me. Tom Schenck, member 52nd Street Development Team.
blume@netmbx.UUCP (Heiko Blume) (07/27/88)
just to clear things up:
CISC prozessors like th MC68000 family members are microcoded which means
that each assembly language op calls a microcode program. you can call that
an interpreter. the microcode is in a onchip ROM which is nice for correcting
bugs and creating special purpose variants of the cpu. however, it has been
shown that some assembly language routines can be faster than the equivalent
microcoded assembly ops which lead to RISC processors like T800 etc. (these
are often also microcoded however).
early processors like 6502 etc. have all their opcodes hardwired, i.e. no
microcode. since the cpu has to determine the type of op after each fetch
one can call that an interpreter too ! however it is more a hardwired one
as opposed to a software interpreter.
the only type of computer that does not interpret its instructions is
the analog computer which has to be programmed with screwdrivers etc...
thats because it doesnt have instructions in the sense of digital
computers.
i hope this leads to a more constructive discussion :-)
--
Heiko Blume # DOMAIN: blume@netmbx.UUCP { BITNET: ( mixed }
Seekorso 29 # BANG : ..!{backbone}!netmbx!blume
D-1000 Berlin 22, West-Germany # Phone : (+49 30) 365 55 71 or ... 365 75 01
Telex : 183008 intro d # Fax : (+49 30) 882 50 65 gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/29/88)
In article <3214@crash.cts.com> maddie@crash.CTS.COM (Tom Schenck) writes: >I have never really like the //gs OR the Mac (ANY of them) for any serious >programming work. Why? Because everything you do, even if you write it in >straight machine code, goes through an intepreter. The OS on the //gs and the >mac has just too much overhead, and is to high-level for me to ever consider >it as a serious programming machine. Funny how in all these newsgroups, the people who say they don't like {whatever the subject of the newsgroup is} give reasons that don't make any sense. The IIGS emphatically does not run machine code "through an interpreter", and its OS imposes no overhead on processes that don't make calls to it (primarily, for disk access).
maddie@crash.cts.com (Tom Schenck) (07/31/88)
In article <8256@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >Funny how in all these newsgroups, the people who say they don't >like {whatever the subject of the newsgroup is} give reasons that >don't make any sense. The IIGS emphatically does not run machine >code "through an interpreter", and its OS imposes no overhead on >processes that don't make calls to it (primarily, for disk access). What I meant, and I didn't relay properly, is that I despise programming in a graphics environment. The //gs has this as an OPTION. And the //gs has some HARD-WIRED overhead that you can NOT avoid. Why else would it run at 2.5Mhz (and sometimes a little slower) when the clock speed is 2.8Mhz? Phantom Slots - A bad idea -- UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!maddie ARPA: crash!pnet01!maddie@nosc.mil INET: maddie@pnet01.CTS.COM Disclaimer : The only company who's thoughts are my own is owned by me. Tom Schenck, member 52nd Street Development Team.