John Hall writes:
> John Hall wrote:
>
> > John Hall wrote:
> >
> > > I think you'll find that the JCB is only updated when a task
> > > switch occurs...
> > >
> > > When a TRAP#n is executed, the PC and SP are saved on the
> > > supervisor stack, hence WL's earlier comment...
> >
> > Oops! PC and SR, of course :-)
> >
> > In supervisor mode, the job's SP is in the USP...
> >
> > > > Now I can forsee there might be a problem if the calling job is
> > > > in SV mode when it makes the Open call, as it would first have
> > > > to exit SV mode before it could set up jobs, open channels and
> > > > things, but it must sooner or later exit that mode, and the
> > > > execution will procede as described.
> > >
> > > This is wrong, for the above reason.
> >
> > Correction. This would work, so long as the job's PC could be found
> > on the supervisor stack by the driver code...
>
> ...which, of course, it couldn't if the job had entered supervisor
> mode via TRAP#0 :-(
>
> (Time to stop talking to myself and have a beer, I think!)
Please keep talking!
Sadly, neither of the above will work as described in /this/ case as, as
someone already pointed out, the trap stores the calling job's PC, and the
matching rte scribbles over any PC value set in the JCB (blithly supported
by the scheduler). The second part of my algorithm had an additional flaw,
as you pointed out.
It is not impossible to know where the calling job's PC is on the SSP, but
this is undocumented and may differ between OSes.
Well, I stipulated from the start that I didnt want to have to THINK, and
obviously, Ive stuck to that ;) That was the first measurement. Glad nobody
cut yet!
To re-discover the point about the above matter it is worth going back to
first principles:
The idea is that a device is used, to hide the complexity for the user and
to allow transparent backward comatibility.
By opening the device for output we want to - seamlessly - send data ( text
and "markup") down it until it comes out the other end via the printer, or
in a file, or even on screen.
There are programs (Proforma and Ghostscript, for example) that, with the
aid of drivers, specific to a given terminal device, are able to output
data - pre-formatted in a certain way - to that device.
The problem I was trying to solve relates to the fact that drivers cant
start jobs or open channels, so some external agent is required. Since that
agent must be active, ie it is not just utility code and/or data, a job
seems to be indicated (rather than a Thing, unless it were an executable
Thing). This job must complete the connection between the application and
the rastering program, because the driver cannot do so itself, as it
involves opening other channels. The driver can also not start any jobs
itself.
This agent is the printer utility - it could be called PRTSRV - which has
to do the following:
Start up the rastering program and connect it to the other end of the
device, or
Spool the converted data coming from the application via PFF first and
then start up the rastering program connected to the file. (However, the
rastering program may have a spooling facility itself, making this step
unnecessay)
Probably a function to abort the current print run should go here too.
The rest is done by the printer device driver (PFF), application and
rastering program
We could have a pre-running job that would snoop on the printer device and
activate when it detected the device was open, but this wastes clock cycles.
Since the printer device driver knows when it is being openened, it seems
sensible that it would somehow activate the job itself when necessary, which
is what the above suggestion was all about.
Another way this might be achieved is by pre-initialising PRTSRV but leaving
it suspended until required. It could be activated by the driver as part of
the Open call like this: The normal way of releasing a suspended job is to
use the trap sms.usjb (d0 = $9) but this is not atomic, and may therefore
not be called within the driver. However, all this trap appears to do is:
shd_usjb
bsr.s shd_ckjx ; check the job exists
bsr.s shd_relf ; release flag
clr.w jcb_wait(a0) ; un-suspend
bra.s shd_done
shd_relf
move.l jcb_rflg(a0),d0 ; get flag address
beq.s shd_rts ; ... none
clr.l jcb_rflg(a0) ; (and clear address)
exg d0,a1
clr.b (a1) ; clear flag
move.l d0,a1
shd_rts
rts
before exiting via the scheduler. Thus the printer device driver could
perform this action before exiting (without involving the scheduler) and the
job should be activated shortly after the Open call returns.
No doubt, while weve been talking all this over, some busy beavers will have
gone and written the whole thing themselves, which is of course very nice,
but defeats the object of collaboration.
Apologies for the length of this mail!
Per
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
