The Datafile PD-CD 5/DATAFILE_PDCD5.iso/utilities/t/tornado/QandA/Paul1r

Text File | 1995-06-26 | 11.1 KB | 194 lines

Quoting DigiLink Email Gateway:

>> finish recoding it into assembler. I also need to write a millisecond
>> timer, as blooming Acorn saw fit not to provide one. The most obvious
>> course is to use the IOC latch 2Mhz timer, but this isn't RPC comp. Any
>> ideas?
> Could do one which is accurate to 10ms :).  I've got something here
> somewhere which will do millisecond timing.  Question is, where!  It
> doesn't appear to be on the hard-drive,  so it must be on one of the
> cartridges... Right. It appears to attach itself to IRQ vector and watch
> for IOC/timer1.  Now as there is no IOC in a RiscPC,  the timer has to be
> derived from another source.  I believe that the IOMD can supply a
> suitable ticker,  but without the TRM I don't know what base address it's
> using.  With any luck, it's using the same addr as IOC, but I'd have to
> knock up some code to try it.

Emm, it's not hugely important as I was merely thinking it'd be nice if
Tornado would increase timer accuracy past 1cs, mainly 'cos I sometimes need
it. Maybe you could pull this code?

>> preemption is inefficiency, as the null return code can't be masked out
>> (ie; the Wimp is always having to page in the task even when it may not be
>> necessary).
> Not sure what you mean about not being able to mask out null's.  Why can't

Wimp_PollIdle, if nothing else, will return 0 as a return code. However, it
will _always_ return close as it can to the time specified in R2. The problem
here is that an app with the null code masked out can sit, unpaged in, for
minutes if not being used and thus doesn't take up any of processor time. A
preempted task has two problems: (a) its code must run for a minimum of 1cs,
and the desktop gets /pretty/ shaky when that happens and (b) quite simply,
not only RO but the Wimp has been designed to hinder preempted code. Believe
me, as I've drawn up the protocols and quite frankly, wimp code cannot be
preempted if it is to function properly. That leaves writing our own
multitasker, but the spirit behind Tornado is not this. Tornado isn't intended
to rewrite RISC-OS, but rather replace bad bits of it and add lots more.

> you?  If you're worried about too much paging,  then how about initialising
> two apps for each real app.  For example "Impression" might take 600k,  but
> it would mask out *all* events.  The co-app "ImpressionMsg" would mask any
> events it doesn't want,  and pass any relevant ones on to the main app.
> The message gatherer might take 16k,  so only 4 pages need to be swapped in
> and not 150.  I am assuming that the wimp isn't silly enough to page in

Two points to this which makes it impractical: (a) Using OS_SetMemMap is
extremely quick, as it's only MEMC's internal pointers that are being altered,
and no memory is being copied. (b) is you would have nightmares writing an app
that way, as one app is *not* allowed access another app's windows, and so
you'd have to implement a message protocol between the two apps to allow the
master to control the slave's windows. Again, this is verging on impractical,
and never mind that but with subtasks, there are going to be *alot* of tasks
running at once anyway!

> It would be nice to pre-empt all applications,  and not force them to be
> written to support it,  but this is a step in the right direction.

As I said above, a wimp app cannot function fully under preemption.

> Distributed processing is currently a big research topic - there are all
> sorts of problems - mainly associated with machines dying.  If some remote
> machine dies then you don't know if it has executed the function you asked
> it to.  For example if you ask a remote machine to add a record to a
> database,  and it falls over for some reason,  how do you know if the
> record was added or not?  Do you try to run the request again and risk two
> copies in the DB?  Do you assume it was completed and risk the record not
> being added?  I think you should leave the hooks for distributed
> processing,  but don't try to write it for the first release!

I dunno about TAOS or anything similar, but Tornado subtasks communicate only
to their parent and their siblings if any. If a child subtask dies for some
unknown reason, or fails to start up, or the subtask being attempted to be
executed isn't really a subtask, Tornado cleans up and returns out of SWI
Tornado_GetSTMessages (used by the parent process to check on the progress of
a subtask and used to receive already processed data) and if the parent
subtask chooses, it may reschedule the subtask, depending on what kind of
error was returned. That's how I intend to get past this. Other subtask
regulations are that the subtask may not be a wimp task, may not use the vdu
drivers, may not save permanent data to a file, and all processed data being
returned either is returned in bits during processing, or in one big lump when
Tornado_ClosedownSubtask is called.
   What do you reckon?

>> Anyway, the way I have it is, upon receiving redraw, Tornado calls
>> Wimp_RedrawWindow and Wimp_GetRectangle and stores the current graphics
>> I think this should work.
> When you store the rectangles,  the Wimp will redraw the icons.  Then
> after you have UpdateWindow'ed,  the icons will be drawn again.  Not a
> major problem,  but it should work.  You may need to keep track of new
> rectangles, though.  If something is being dragged accross your window,
> then you might get new rectangles to redraw before you have redrawn the
> old ones.

See my problem with inefficiency? If you want to amalgamate all returned
rectangles while still allowing for the window to be resized, scroll offsets
altered etc then you're looking on some serious processing, and this is in
/addition/ to the 1cs already being taken up.

> Do you have to auto compress after each heap op?  Surely you only need to
> do it when you fail to allocate memory:
> * User requests block which is smaller than largest_block.  Allocate memory.
> * User requests block which is larger than largest_block.  Compact heap.
> If request is still larger,  extend heap or fail.  Allocate memory.

:-) _IF_ you had studied the heap data structure more carefully, you'd see
that all reloc and non-reloc blk's addresses are kept in lists. Allocating a
block may increase the size of the list, which may extend the heap to move the
bigger block out, leaving a big hole! This causes major fragmentation unless a
garbage is done. Anyway, the garbage can be optionally disabled, and even then
it would be pretty quick, being written in C and all.

>PRM> RISC OS 2 and 3 place strong restrictions on the heap: the base of the
>PRM> heap as specified in R1 must be word aligned and less than 32Mbytes,
>PRM> and the size of the heap must be a multiple of 4 and less than 16Mbytes.
>PRM> In RISC OS 3.5 platforms the only restrictions are that the base of the
>PRM> heap must be word-aligned,  and the size must be a multiple of 4 bytes.
> If they have changed the format,  then they haven't told anyone about it.

Twats! The RO2 heap manager isn't worried about those restrictions either:
It's merely that there wouldn't be enough memory to do this anyway! RO2 & 3
could only ever take a max of 16Mb anyway. And the highest address was
32Mbytes!

>> and reruns itself, keeping the original app intact. When the new app has
> Isn't it a bit wasteful on memory to have two copies of an app loaded at
> once? For example,  Impression Style with no files loaded takes up 600K
> of wimpslot.  This is no problem on a 9Mb machine,  but what about 2Mb
> users?  Here's a possible solution.  Howabout the old app saves all it's
> data into tfs: and the new app then loads it back.  A swi
> "Tornado_ReLoadApp" could do it in the background:  the app saves it's
> data into tfs: and then calls the swi.  The new app is loaded over the
> top of the old one,  and initialised.  When the Tornado App Manager sees
> a Message_TaskStarted it can send a Message_DataLoad to the application
> to force it to load data back from tfs.

For a start, it would be strongly recommended that no Tornado app need quit
and reload just because of a config change. I've never had to, and I've seen a
well-written app need to either.
   Add to this, there's virtual memory so a 2Mb owner would merely notice lots
of disc activity. Also, all files and data in apps is *already* contained in
tfs:, if you had fully read the brief. So there would never be a case of two
copies of the same data being in memory, as merely it becomes a case of the
old app passing the handles of the data blocks to the new task. Very easy. And
if an app needs to OS_Find it's files in, which it shouldn't, it can do so
from tfs:.

>> Is done. Tornado hooks into Address exception etc. and catches any such
> Hooking on to hardware vectors is not the same under RISC OS 3.5.  Two
> reasons: the module area is now at &2100000.  If you were to assemble the
> instruction "b &2100000" and disassemble it you will find that you've run
> out of bits (dis: b &fe100000).  The second reason is the new processor
> modes with the ARM6 and above - when an exception occurs you get put in a
> 32 bit mode - 26bit code doesn't work in 32 bit modes, so you have to
> switch back to 26bits.  Fortunately there is a swi which can help you:  swi
> "OS_ClaimProcessorVector",  but looking at the docs it seems that you can't
> use the addrex vector (prefetch and data aborts are supported).

:-). Hehe, I wasn't planning to overwrite the hardware vectors, but have
Tornado hook itself into the environment handlers. I think this works on the
RPC too? :-)
   Also, any code written specifically for the RPC will use the 32bit mode
/all/ the time. Has to, as it's in the aims that Tornado code should be
superior to other code where possible.

> - TFS
> Does not work.  I've assembled it,  and loaded the module.  Typing *tfs is
> fine, but any further * commands (such as *. *info *ex) fail.  They all
> data-abort at &01c02084 - according to my memory map this is near the
> bottom of the system heap (starts at &01c02000).

Works okay on RO3.1!

> When I try to shutdown the computer,  I get the error FS_Entry Func 16 not
> supported by tfs - I've looked up Func16 in the book and it is just called
> shutdown.  On entry,  r0=16 - I think you can safely ignore this one and
> not bother with the error.

This is *BLASTED* RO3+ for you! RO3 Fileswitch does lots of Func16 all the
time, even if they aren't supported (which according to my PRM's it doesn't
have to be really). TFS uses it own method of implementing wildcards, like the
RO2 PRM's say it should. Blasted RO3!

> Works,  but garbage collection doesn't appear to be very good.  At the left
> of the bar,  it's mostly white with a few black lines;  to the right of the
> used portion it is mostly black with a few white lines.  The right hand
> side of the heap is completely black (because it's unused).

:-) - exactly! For a start, the black lines are actually minute pockets of
small bytes, like eight or sixteen, but the renderer plots them as looking too
big (smallest it can do is one line thick).
   The right is black, and blank, because it's meant to be! In reality,
Tornado would auto-shrink and extend if necessary and the appropriate bits
were set in Tornado_HeapInit. The HeapExt program, which is a prototype,
doesn't implement the full set of Heap+ facilities.