brett@sylvester-tr.umd.edu (Brett S Bourbin) (04/17/89)
In the Jan/Feb 1989 issue of Amiga-Mail, under the "Official Warnings to ROM-Jumpers, Structure-Hackers, and Others", it states that you should NOT use the TAS assembly instruction. What is the reason for this? In my sine/cosine routines, I use the TAS instruction to set the sign flag if the result is negative. Sure, I could change it to MOVEQ #-128,D1, but why is this instruction "bad"? --Brett S Bourbin __ __ _ __ _ Instructional Computing Programs -- Univ of Maryland | || | / || || \ | || || || || | INTERNET: brett@SYLVESTER-TR.UMD.EDU | || || || || | bbourbin@UMD5.UMD.EDU \_||_/ |__||__||__| BIX: brettb College Park BITNET: bbourbin@UMDD
rap@rap.ardent.com (Rob Peck) (04/18/89)
The poster referred to a warning from CATS not to use the TAS instruction. As I remember, TAS is an instruction during which the 68000 believes that it has the bus for the entire instruction execution time, and effectively runs what it believes to be a Read/Modify/Write cycle. But the custom chips don't take too nicely to this kind of activity and can take away the bus before the instruction can be completed. I don't know what effect that has on the instruction or the processor, but it can, at the very least, make the instruction suspect. Rob Peck
erd@tut.cis.ohio-state.edu (Ethan R Dicks) (04/18/89)
In article <5881@ardent.UUCP> rap@rap.ardent.com (Rob Peck) writes: >The poster referred to a warning from CATS not to use the TAS instruction. >As I remember, TAS is an instruction during which the 68000 believes >that it has the bus for the entire instruction execution time, and >effectively runs what it believes to be a Read/Modify/Write cycle. > >But the custom chips don't take too nicely to this kind of activity >and can take away the bus before the instruction can be completed. >I don't know what effect that has on the instruction or the processor, >but it can, at the very least, make the instruction suspect. > >Rob Peck To add my $.02, and add some light... On page Introduction-5 of the New (and Improved!) RKM for AmigaDOS 1.3, there is a section labeled "Additional Assembler Development Guidelines," to which the original poster probably refered... The first entry reads: o Do not use the "TAS" intruction on the Amiga. System DMA can conflict with this instruction's special indivisible read-modify-write cycle.+ I assume that this warning refers to the intended use of the TAS instruction to implement semaphores. Normally, the Assembler programmer can use the TAS to check the state of a locking bit, and then set it in an indivisible succession, to permit two processes to use a common memory location as a spinlock an not get into a race condition. For example... Process A executes a TAS on a memory location containing a 0. This will set a bit in the location as well as set the Z bit in the Processor status register. Before the next instruction of A can begin, the scheduler switches tasks and starts process B, which also executes a TAS on the same location. Because A already set the bit, the Z flag in the processor status word is *not* set for process B, telling it that it did NOT get the lock, and should try again later. The warning is intended to warn programmers that the TAS is NOT atomic in the Amiga because of the possible actions of the custon chips. Structures which are sensitive to updates from multiple processes are NOT adequately protected by the TAS mechanism. There should be no problem using the TAS instruction if the programmer does not mind having the test and set possibly interrupted. If it is used as the proginal poster intended, for setting a bit in a memory location, there should be no problem, but using the BSET instruction might be more appropriate, to avoid confusion. -ethan + Quoted from _Amiga ROM Kernal Reference Manual: Includes and Autodocs_, Copyright (C) 1989 by Commodore-Amiga, Incorporated, published by Addison-Wesley Publishing Company, Inc. Reprinted without permision. -- Ethan R. Dicks | ###### This signifies that the poster is a member in Software Results Corp| ## good sitting of Inertia House: Bodies at rest. 940 Freeway Drive N. | ## Columbus OH 43229 | ###### "You get it, you're closer."
gregmarq@pnet02.cts.com (Greg Marquez) (04/18/89)
Bret,
The new Includes & Autodocs manual says "Do not use the 'TAS'
instruction on the Amiga. System DMA can conflict with this instruction's
special indivisible read-modify-write cycle." I take this to mean that it is
not a very "bus sharing friendly" instruction. . .
----------------------------------------------------------------------------
UUCP: {ames!elroy, <backbone>}!gryphon!pnet02!gregmarq
INET: gregmarq@pnet02.cts.com
FOR REALS: Richard G. Marquez ("Greg")
Echidna Software \|// Echidna - The best little
3501 Jasmine Avenue #15 _oo // monotreme money can buy.
Los Angeles, CA 90034
----------------------------------------------------------------------------
'Cause when love is gone, there's always justice.
And when justice is gone, there's always force.
And when force is gone, there's always Mom.
- Laurie Andersondirks@canoe.cis.ohio-state.edu (william r dirks) (04/18/89)
In article <43928@tut.cis.ohio-state.edu> Ethan R Dicks <erd@cis.ohio-state.edu> writes: >The warning is intended to warn programmers that the TAS is NOT atomic >in the Amiga because of the possible actions of the custon chips. Structures >which are sensitive to updates from multiple processes are NOT adequately >protected by the TAS mechanism. The TAS instruction _is_ indivisible with respect to the CPU itself. Though it may be possible for DMA to _suspend_ the instruction and write to the memory location in quesiton, it is not possible to have an interrupt in the middle of an instruction. This is because the 68000 does not support instruction continuation. Once an instruction is begun, it will run to completion before any interrupt (including a context switch) is handled. Guaranteed. Now the 68010 and up DO support instruction continuation, but I believe the TAS instruction (and CAS, CAS2 on the '020) are handled differently (restarted from the beginning) to guarantee an atomic operation. Although I admit I can't find where it says that. ______________________________________________________________________ | Name: Bill Dirks | | Address: dirks@baloo.eng.ohio-state.edu | | Quote: "Survival and preservation must cancel out programming." | |_________________________Star_Trek,_"What_Are_Little_Girls_Made_Of?"__| -=- ______________________________________________________________________ | Name: Bill Dirks | | Address: dirks@baloo.eng.ohio-state.edu | | Quote: "Survival and preservation must cancel out programming." |
andy@cbmvax.UUCP (Andy Finkel) (04/19/89)
In article <3082@haven.umd.edu> brett@sylvester-tr.UMD.EDU (Brett S Bourbin) writes: > > In the Jan/Feb 1989 issue of Amiga-Mail, under the "Official Warnings >to ROM-Jumpers, Structure-Hackers, and Others", it states that you should >NOT use the TAS assembly instruction. What is the reason for this? The 68000 makes a couple assumptions about instructions like TAS (those of the read-modify-write type). One is that the 68000 controls the memory bus. The other is that the read-modify-write cycle is atomic. On the Amiga neither is necessarily true; the custom chips control the memory bus, and read-modify-write may be interrupted. So switch to the MOVEQ. You'll be happier. We'll be happier :-) -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "There is no programming problem that cannot be solved by proper "application of the Delete command." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
rchampe@hubcap.clemson.edu (Richard Champeaux) (04/21/89)
In article <757@manta.NOSC.MIL>, dwi@manta.NOSC.MIL (Steve Stamper) writes: > Does this mean I can use the TAS instruction safely in programs which > are designed to run only on the A2620 equipped systems, like programs > for my own use? > > -Roger Uzun Why don't you just use BSET. It will perform the same function, and I believe it doesn't take any more bytes. The TAS instruction was designed to be used in multiprocessor systems. It keeps the Address Strobe low so that another processor can't access the memory in the middle of the instruction; even with most multiport memories. The BSET command is a little more friendly, however. It also tests the bit before setting it, but it allows the bus to taken by another device in the middle of the instruction. It will still work for semaphores in a single processor system, since the 68000 will not service an interrupt until the completion of the current instruction. Rich Champeaux Clemson University
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (04/24/89)
In article <3082@haven.umd.edu> brett@sylvester-tr.UMD.EDU (Brett S Bourbin) writes: > In the Jan/Feb 1989 issue of Amiga-Mail, under the "Official Warnings >to ROM-Jumpers, Structure-Hackers, and Others", it states that you should >NOT use the TAS assembly instruction. What is the reason for this? > A zillion other people have offered explanations. Now it's my turn. TAS uses an indivisible memory cycle to do its work. It's supposed to be used in multi-processor systems, where many CPU's share the same memory. TAS causes the CPU to grab the memory location and hold onto it until it's finished modifying it, thereby preventing other CPU's from possibly inspecting the datum before the modification is complete. It's a form of hardware semaphore facility. However, the Amiga doesn't have multiple CPU's (the Copper doesn't count in this instance). So TAS is not needed, and as has already been explained, the behavior of TAS on the Amiga is guaranteed to be indeterminate. Use the BSET instruction instead. It's functionally similar. It even runs a little quicker. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
dillon@HERMES.BERKELEY.EDU (Matt Dillon) (04/25/89)
: In the Jan/Feb 1989 issue of Amiga-Mail, under the "Official Warnings :to ROM-Jumpers, Structure-Hackers, and Others", it states that you should :NOT use the TAS assembly instruction. What is the reason for this? : : In my sine/cosine routines, I use the TAS instruction to set the sign :flag if the result is negative. Sure, I could change it to MOVEQ #-128,D1, :but why is this instruction "bad"? : :--Brett S Bourbin People often miss the usefulness of the Scc instruction... set according to condition. i.e. seq, sne, ... a very useful instruction. Using Scc or any of the bit manipulation instructions bset, bclr, btst will probably do what you want even better than tas, which should not be used on the amiga. -Matt
karl@sugar.hackercorp.com (Karl Lehenbauer) (04/30/89)
In article <11394@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > TAS uses an indivisible memory cycle to do its work. It's supposed > to be used in multi-processor systems, where many CPU's share the same > memory. Isn't TAS useful on a single CPU system, though, for providing fast, uninterruptable test and set for use as a semaphore, without having to turn off interrupts? -- -- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee -- Usenet BBS (713) 438-5018
pavel@dgp.toronto.edu (Pavel Rozalski) (05/01/89)
In article <10819@mcdphx.phx.mcd.mot.com> dbk@teroach.UUCP (Dave Kinzer) writes: >In article <3773@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >> >>Isn't TAS useful on a single CPU system, though, for providing fast, >>uninterruptable test and set for use as a semaphore, without having >>to turn off interrupts? >> >>-- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee >>-- Usenet BBS (713) 438-5018 > > Semaphore to who? Another task? That's what the operating system is >in there for. It takes care of all the system dependent stuff. > > I think (really) that this whole discussion boils down to: The TAS >instruction should not be used in an Amiga because it has a problem with >the custom chips. YOU WERE WARNED! That's it, end of any discussion >appropriate to this newsgroup. Occasionally one may wish to have a lightweight method of accessing shared memory without the burden of an OS call. Seems as if Motorola would have provided the TAS in the 68000 series for that purpose. Pavel Rozalski UUCP: ..!uunet!dgp.toronto.edu!pavel Bitnet: pavel@dgp.utoronto Internet/Ean: pavel@dgp.toronto.{edu,cdn}
dbk@teroach.UUCP (Dave Kinzer) (05/01/89)
In article <3773@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: > >Isn't TAS useful on a single CPU system, though, for providing fast, >uninterruptable test and set for use as a semaphore, without having >to turn off interrupts? > >-- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee >-- Usenet BBS (713) 438-5018 Semaphore to who? Another task? That's what the operating system is in there for. It takes care of all the system dependent stuff. I think (really) that this whole discussion boils down to: The TAS instruction should not be used in an Amiga because it has a problem with the custom chips. YOU WERE WARNED! That's it, end of any discussion appropriate to this newsgroup. #define Net_police_mode OFF | // GOATS - Gladly Offering All Their Support Dave Kinzer (602)897-3085| | // >> In Hell you need 4Mb to Multitask! << uunet!mcdphx!teroach!dbk | | \X/ #define policy_maker(name) (name->salary > 3 * dave.salary) |
rchampe@hubcap.clemson.edu (Richard Champeaux) (05/02/89)
In article <3773@sugar.hackercorp.com>, karl@sugar.hackercorp.com (Karl Lehenbauer) writes: > In article <11394@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > TAS uses an indivisible memory cycle to do its work. It's supposed > > to be used in multi-processor systems, where many CPU's share the same > > memory. > > Isn't TAS useful on a single CPU system, though, for providing fast, > uninterruptable test and set for use as a semaphore, without having > to turn off interrupts? > > -- > -- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee > -- Usenet BBS (713) 438-5018 As I and other people mentioned before, BSET will perform the same function as TAS and will work on the Amiga. TAS won't let anything else take the bus durring the instruction, therefore it works great for semaphores on multiprocessor computers, but it won't work on the Amiga. BSET, how ever, also tests the bit before setting it, allows another device to grab the bus durring the instruction, and lets you set any bit as well. You don't have to turn off interrupts before using it, because the 68000 doesn't service interrupts until the current instruction is completed. Rich Champeaux Clemson University
new@udel.EDU (Darren New) (05/02/89)
In article <8904302141.AA21035@explorer.dgp.toronto.edu> pavel@dgp.toronto.edu (Pavel Rozalski) writes: >Occasionally one may wish to have a lightweight method of accessing >shared memory without the burden of an OS call. As I remember, Forbid() and Permit() (or at least the asm macros thereof) are just one or two instructions long and don't involve any OS calls. I think they work by just incrementing or decrementing flags, maybe in the Task structure (requiring that you find this via the OS, but only once). How much more lightweight do you want? -- Darren
usenet@cps3xx.UUCP (Usenet file owner) (05/02/89)
In article <3773@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >Isn't TAS useful on a single CPU system, though, for providing fast, >uninterruptable test and set for use as a semaphore, without having >to turn off interrupts? Thats what the BSET, BCLR, BCHG, etc.. are for. Those instructions won't be interrupted by a task switch, but their memory read/write cycles could be interleaved with memory accesses from other processors, like another CPU, or the copper, or even the blitter. Generally though, the copper and blitter would not be using memory that programs are using for semaphores and the like. Perhaps the badness of TAS and alternate solutions should be included in the RKMs, since it apparently causes problems for a lot of programmers.
Sullivan@cup.portal.com (sullivan - segall) (05/03/89)
>In article <10819@mcdphx.phx.mcd.mot.com> dbk@teroach.UUCP (Dave Kinzer) writes: >>In article <3773@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >>> >>>Isn't TAS useful on a single CPU system, though, for providing fast, >>>uninterruptable test and set for use as a semaphore, without having >>>to turn off interrupts? >> >> Semaphore to who? Another task? That's what the operating system is >>in there for. It takes care of all the system dependent stuff. >> > >Occasionally one may wish to have a lightweight method of accessing >shared memory without the burden of an OS call. Seems as if Motorola >would have provided the TAS in the 68000 series for that purpose. > Thinkee before speakee. All single instructions are indivisible on a one processor system. If you want to make your own semaphores you can do so without risk using any instruction which both reads/sets flags, and writes. The 680x0's don't save enough machine state info to resume an interrupt from the middle of an instruction. -Sullivan Segall _____________________________________________________________ /V\ Sully set the example: to fly without moving. We shall ' learn to soar on wings of thought. And the student will surpass the teacher. To Quote the immortal Socrates: "I drank what?" -Sullivan _____________________________________________________________ Mail to: ...sun!portal!cup.portal.com!Sullivan or Sullivan@cup.portal.com
bryce@cbmvax.UUCP (Bryce Nesbitt) (05/26/89)
In article <3773@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: > >Isn't TAS useful on a single CPU system, though, for providing fast, >uninterruptable test and set for use as a semaphore, without having >to turn off interrupts? For a single CPU system, the BSET and BCLR instructions are identical to TAS. The 68000 does not interrupt instructions in the middle. TAS is only needed for multiple CPUs. BSET and BCLR first test, then set bits. "poof". DON'T USE TAS. -- |\_/| . ACK!, NAK!, EOT!, SOH! {O o} . Bryce Nesbitt, Commodore-Amiga, Inc. (") BIX: bnesbitt U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce Lawyers: America's untapped export market.
deven@rpi.edu (Deven Corzine) (05/26/89)
In article <6988@cbmvax.UUCP> bryce@cbmvax.UUCP (Bryce Nesbitt) writes:
For a single CPU system, the BSET and BCLR instructions are identical
to TAS. The 68000 does not interrupt instructions in the middle.
TAS is only needed for multiple CPUs.
I wish this would be noted in the RKM's (such as the new 1.3 Includes
& Autodocs RKM) with the restriction not to use TAS, so people will
realize that there IS an alternative...
Deven
--
shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847
shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America
deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>>
"Simple things should be simple and complex things should be possible." - A.K.