Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!jb10320
From: jb10320@uxa.cso.uiuc.edu (Desdinova)
Newsgroups: comp.sys.apple2
Subject: Re: Building a NEW computer
Message-ID: <1990Dec6.171148.9281@ux1.cso.uiuc.edu>
Date: 6 Dec 90 17:11:48 GMT
References: <10895.apple.net@pro-angmar>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 43

In article <10895.apple.net@pro-angmar> m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes:
[ mentions Apple's apparent early disregard for interrupts ]
>ProDOS does provide you with methods of hooking your routines in using a very
>nice clean manner but then at EVERY interrupt, ProDOS runs a little ditty
>before handing off control to your code.  (I grant you, they did it for the
>right reasons, to return the machine to a known state before you get control)
>but hell, that's not their judgement to make beyond the absolute minimum.

   With the IIgs and GS/OS, interrupts are actively used for all sorts of
system tasks. The heartbeat timer, appletalk and serial ports, keyboard,
etc. all generate interrupts and GS/OS depends on them.
   What you're probably referring to is vectored vs. single line interrupts.
Tis' true the 6502/65816 doesn't have vectored interrupts, but adding them
would be a tradeoff against system reconfigurability- in a PC you can only
have a certain number of interrupt generating devices- in a II there is no
limit.

>Aside from all that, the II line lacked a non-preempt style of instruction
>that would allow you to run (cleanly) multiple tasks.  Even the oldest IBM-PC
>had an instruction to increment a memory word that blocked all attempts at
>prememption until it completed.  Using this, you could signal tasks into and
>out of a run/ready state.  We ain't got it.  HOLD IT!  Before the flames get
>turned on, I am not saying I should be able to run a uucp transfer while I
>recompile the great American program in the background, but even little things
>like clean print spoolers, alarm clocks and the such are hindered in their
>abilities without such a thing.

   The 6502 does indeed lack a Test-And-Set instruction, but the 65c02
and 65816 both have it.  TSB or TRB are all that's needed for mutual
exclusion checking in a preemptive environment. (Note this doesn't hold
true for multiple processor systems, but there aren't any, so I'm not
worried.)    Note that the 6502 DOES have an indivisible INC memory location
instruction, but INC alone is not good enough for mutex.

>Thanks for the use of the soapbox, "NEXT!"
Thank you!


--
Jawaid Bazyar               | Being is Mathematics 
Senior/Computer Engineering | Love is Chemistry
jb10320@uxa.cso.uiuc.edu    | Sex is Physics
   Apple II Forever!        | Babies are engineering