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
ts@cup.portal.com (Tim W Smith) (12/29/89)
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com says: > In article <25347@ubvax.UB.Com> fred@ubvax.ub.com.UUCP (Fredrik Noon) writes: > >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. It should be possible to "break" TAS on a standard 68000 if the /DTACK generation logic determines when to deassert /DTACK by looking at /AS. A 68000 read bus cycle goes like this: 68000 Other thing ----- ----------- put address on bus assert /AS assert /UDS and/or /LDS put data on bus assert /DTACK deassert /AS deassert /UDS and/or /LDS stop putting data on bus deassert /DTACK The logic that generates /DTACK wants to know when the 68000 has the data so that /DTACK can be unasserted. The simplest way to do this is to look at /AS. The more complicated way is to look at both /UDS and /LDS ( an extra AND gate! Gotta watch those pennies...:-) ). A read-modify-write cycle is similar, except that after the 68000 has gotten the data, it deasserts /UDS and /LDS, but does *NOT* deassert /AS. It then waits for /DTACK to be deasserted. The data is then placed on the bus and /UDS and/or /LDS are asserted. When it gets /DTACK it will deassert /AS, /UDS, and /LDS. If the logic that generates /DTACK is watching for /AS to be deasserted to know when to deassert /DTACK, a read-modify-write cylce will hang it up, since /AS will not be deasserted! Anyway, that's how to "break" TAS on a 68000. The 68020 and 68030 work quite a bit differently. I don't think there is an easy way to "break" TAS on these in the sense of the above ( i.e., hang the system ). What I don't understand is why you need to use a TAS instruction on a Mac. Do you have another bus master on your motherboard? Tim Smith
tim@hoptoad.uucp (Tim Maroney) (12/30/89)
In article <25470@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >What I don't understand is why you need to use a TAS instruction on >a Mac. Do you have another bus master on your motherboard? It's a convenient way to synchronize between interrupt levels without disabling interrupts, even if it is a bit of overkill for the job. I suppose that BCLR could do much the same thing, but I didn't know about that instruction when I was writing the code in question. Still, so far as I know, it's been tested on all Mac models and there has not been a problem with TAS. From what you say, if there is a problem the system should hang the first time TAS is invoked, and this certainly has not happened. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Never ascribe to stupidity what can adequately be explained by malice.
Hueras@cup.portal.com (Jon F Hueras) (12/31/89)
FYI, the TAS instruction does have non-standard behavior on the Mac/XL. I'm not certain, but I believe it has something to do with the home-grown MMU on the Lisa.
jimc@isc-br.ISC-BR.COM (Jim Cathey) (01/09/90)
In article <25470@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com says: >> 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. > >It should be possible to "break" TAS on a standard 68000 if the >/DTACK generation logic determines when to deassert /DTACK by >looking at /AS. >... >The logic that generates /DTACK wants to know when the 68000 has the >data so that /DTACK can be unasserted. The simplest way to do this >is to look at /AS. The more complicated way is to look at both >/UDS and /LDS ( an extra AND gate! Gotta watch those pennies...:-) ). UDS and LDS come out much later than AS on write cycles, so they aren't useful under a lot of circumstances (unless you like lots of wait states). >A read-modify-write cycle is similar, except that after the 68000 has >gotten the data, it deasserts /UDS and /LDS, but does *NOT* deassert >/AS. It then waits for /DTACK to be deasserted. The data is then >placed on the bus and /UDS and/or /LDS are asserted. When it gets >/DTACK it will deassert /AS, /UDS, and /LDS. > >If the logic that generates /DTACK is watching for /AS to be deasserted >to know when to deassert /DTACK, a read-modify-write cylce will hang >it up, since /AS will not be deasserted! That's not the only problem possible, nor even the worst! Depending on the way the memory timing is generated, a TAS cycle can totally screw up RAS and or CAS to the memory which will cause corruption of 'random' parts of memory. Designing memory timing logic that will work _at full speed_ for all the cycle types isn't trivial, especially when it's the first time you've worked with the 68000, and even more so when you're trying to keep the cost down by avoiding expensive delay lines. [It can even be very confusing to talk about since there're three different read-modify-write sequences: CPU bus cycle (TAS), instruction (ADD, BCLR, etc.), and the DRAM's own RMW cycles.] +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"