ag@amix.commodore.com (Keith Gabryelski) (12/18/89)
In article <14960@boulder.Colorado.EDU> kuo@boulder.Colorado.EDU (KUO ANDY Y) writes: >It is a fact that [...] 68xxx chip is superior than [...] 80xxx(not >include 80486). I dunno, have you seen the latest recalls of the 80486 and the many notices of bug reports? Follow-ups set to alt.religion.computers; possibly a better place would be alt.flame. Pax, Keith -- ag@amix.commodore.com Keith Gabryelski ...!cbmvax!amix!ag
ag@amix.commodore.com (Keith Gabryelski) (12/20/89)
In article <213@amix.commodore.com> I wrote: >[something inane, but mainly the subject line did it] I apologize; I even managed to offend myself with this last posting, not to mention the person that sent me e-mail. Pax, Keith Ps, I think this System V Release 4 port is slowly driving me over the edge. Follow-ups to me. -- ag@amix.commodore.com Keith Gabryelski ...!cbmvax!amix!ag
fred@ubvax.UB.Com (Fred Noon) (12/22/89)
As a programmer, I am more fond of the 68k architecture. Unfortunately, Apple seems never to have thought of its main chip as being in any way a competitive advantage. After IBM PC compilers had broken the 64k data segment/array size barrier with the various memory models, and folks were hard at work breaking the 640k application memory barrier, Apple was selling 128/512k 68000 machines whose resource loader limited the first compilers to 32k arrays, etc. I beleive that I have my chronology right here, but the point is that Apple thought nothing of coming up with a resource manager that could only handle 32k (which has, after customer complaint, been fixed). A more annoying deficiency (as it will be with us for a while) is that Apple castrated the 68k test-and-set instruction after the Mac+. It expects fancier software (e.g., System 7) to run on the strength of MHz and MMUs alone? Not all Macs have the latter, but I know of no good reason why all Macs can't execute a TAS anymore (can somebody else?). I wish Apple appreciated the building blocks they have (or have had and have squandered) instead of trying to fix everyone up with CAD stations and multi-media spreadsheet servers.
tim@hoptoad.uucp (Tim Maroney) (12/23/89)
In article <25347@ubvax.UB.Com> fred@ubvax.ub.com.UUCP (Fredrik Noon) writes: >As a programmer, I am more fond of the 68k architecture. Unfortunately, >Apple seems never to have thought of its main chip as being in any way >a competitive advantage. After IBM PC compilers had broken the 64k >data segment/array size barrier with the various memory models, and >folks were hard at work breaking the 640k application memory barrier, >Apple was selling 128/512k 68000 machines whose resource loader limited >the first compilers to 32k arrays, etc. I beleive that I have my >chronology right here, but the point is that Apple thought nothing of >coming up with a resource manager that could only handle 32k (which >has, after customer complaint, been fixed). No, this is not correct. First of all, the reason for the 32K limits was not in fact related to the Resource Manager. It has to do with the 68000's 16-bit offset addressing modes. Of course, a smarter compiler and linker can figure out ways around these, but the first ones, not surprisingly, did not. So when you say that Apple is at fault for not taking full advantage of the 68000, you should be blaming the 68000 for only having 16-bit offset addressing modes. And even then, arrays were not limited to 32K. You just had to allocate them from the heap instead of putting them in globals. Incidentally, way back when, there was a bug with some resources over 32K, though not all of them. It was bug, and was never intended to be a feature (there was a TST.W where there was supposed to be a TST.L at one point in the system software). It was fixed fairly quickly. See Mac Tech Note #54. >A more annoying deficiency (as it will be with us for a while) is that >Apple castrated the 68k test-and-set instruction after the Mac+. It >expects fancier software (e.g., System 7) to run on the strength of MHz >and MMUs alone? Not all Macs have the latter, but I know of no good >reason why all Macs can't execute a TAS anymore (can somebody else?). Huh? I've used TAS instructions within the last two years and they've worked, though not lately. I don't see how Apple could break part of the hardware instruction set; I'm pretty sure they use standard off-the-shelf 68K processors with no custom microcode. >I wish Apple appreciated the building blocks they have (or have had >and have squandered) instead of trying to fix everyone up with >CAD stations and multi-media spreadsheet servers. Huh? Is this a complaint about the unbundling of MacPaint and MacWrite? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "This signature is not to be quoted." -- Erland Sommarskog