The Datafile PD-CD 5/DATAFILE_PDCD5.iso/utilities/t/tornado/TNdemo2/_TShell

Text File | 1996-05-29 | 15.6 KB | 294 lines

Tornado shell
-=-=-=-=-=-=-
   These are various notes on the tornado shell, grouped into various topics.

Shell's wkspace:
+00: Address of complete list of pages in the machine and their status'
+04: Address of complete list but with everything protected; all pages
     with protection 2 and between the end of our wimpslot and 16Mb moved
     elsewhere.
+08: page size in bytes
+12: number of pages
+16: Rating of ARM in MIPS
+20: Time given to avrg priority process
+24: Max total time in between wimp polls
+28: 256 bytes Wimp_Poll wkspace
+32: 1k tornado user stack
+36: Wimp task handle

List of local tornado apps known of by tornado
4 words of address of this machine
1 word of number of this processor

For each task:
Pages that hold the main image (&8000)
Pages that hold the private heap (variable, but ATM @ &800000)
Priority of task (64 is average, 0 is don't task, 255 is max)
Is it in single-tasking mode? If so, is it pollable?




















The Shell itself
-=-=-=-=-=-=-=-=
   The shell, upon startup, registers itself with the kernel and claims a
large number of SWIs and service calls. It then starts itself up as a wimp
task with a dynamic memory area, and creates the program environment within
its slot.
   Within the user code which polls the Wimp, there is a section of code
which interfaces with the RISC-OS Wimp (manages window redraw requests from
the Wimp, mouse and keypresses from the Wimp etc). It also performs dynamic
system performance optimisation, and calls the interrupt code responsible for
multitasking the tasks. To this it passes a stack, through which it runs,
calling each task in turn for whatever amount of time.
   Depending on user preferences, CPU power available, the load on the
RISC-OS Wimp, the load on the tornado multitasker etc, control may be passed
back to the RISC-OS Wimp without cycling all of the tasks/processes. This is
done to prevent the RISC_OS Wimp becoming jerky, because as shown below total
turnaround may take up to a second.


Multitasking
-=-=-=-=-=-=
   The preemptive multithreading task switcher employed by the tornado shell
currently performs the following:

   * It aims to turnaround all of the tasks (ie; give control to all tasks)
in 50cs, or half a second. This value can be altered by the user to a fixed
value, or more appropriately tornado can be allowed to manage the value
itself, allowing it to vary between 10cs and 100cs, updated dynamically to
reflect the current system's requirements.

   * Each task has a priority value attached to it which is between 0 and
255, with 64 being average. The total turnaround time is divided up into
weighted parts according to their relative priorities. The maximum priority a
normal task may have is 192, and the lowest 1. A priority of 0 means the task
does not have any user code it wants multitasked.

   * After the times given to each task have been decided, the task swapping
starts. For each task, the following happens:

    (i): Current time is noted from OS_ReadMonotonicTimer, and a callback
scheduled in whatever the time allocated to this task is.
   (ii): Task's memory is paged into &8000, with its private heap into
&808000. As you can see, this limits program size to 8Mb, and far worse is
file size is also limited to 8Mb. However, there is no reason why on later
machines the entire program image and heap cannot be shifted to outside the
32Mb boundary, leaving a page at &8000 so things hopefully wouldn't fall
over for the language. Worst case scenario is that only the program size will
be limited to 16Mb, which in any case is the same as RISC-OS, so however they
get around it so will tornado. Personally, I still can't see why they didn't
kill all those restrictions and do it properly, but then I guess I'm only one
bloke compared with all the wisdom (and expertise) of Acorn! ;)
  (iii): Tornado checks what the user is doing, and does whatever the visual
commands currently known to it dictate (start new threads, pass information
to a thread or ticker, whatever).
   (iv): Whatever redraw threads for this task are kicked in, with each
thread getting 1cs of time. Note that threads may create new threads, either
in the task or new redraw threads themselves.
    (v): Assuming we still have some time left (which may not be true, in
which case the program itself doesn't get control this cycle), each of the
threads running in the program are given 1cs of time until this task's
allocation runs out, or else threads are given weighted divisions of the
time left depending again on system performance and/or user preferences.
   (vi): Next task.

   The task is monitored constantly. Every second an interrupt routine
sitting on a ticker checks to see preemption is working correctly. If for
some reason the callback system has stopped, a forced termination is made.
This is quite powerful - only disabling interrupts can stop it. To the user,
a box will appear saying that the task seems to have crashed and asking what
to do. Meanwhile, multitasking on other threads/tasks continues.
   Facilities are also provided for hogging the processor. A task may request
complete control of the processor, and it will get it if it's enabled.

   You will notice that on slower machines most of the CPU time will be spent
switching tasks and doing housekeeping. I have managed to get preemptive
multithreading redrawing working on a test program, and let me tell you it
sure *is* slow. The desktop moves quite fluidly, but boy is it slow.
   The above method ensures a very flexible and powerful method of CPU
sharing, but it is subject to cascade overload ie; the more things are going
on, the more time is spent in switching between them, and as you can see
there comes a threshold when simply the switching alone is enough to fill
quotas, and before you know it the turnaround time is exceeded.
   Tornado, if enabled, will then adjust the turnaround time to get all the
tasks in. It will not let tasks go without control for long periods, so
serial programs etc will be kept up to date well-enough (although no data
will be lost as there are two dynamically controlled pipes managed by
interrupt code on every i/o device, in addition to another two individual
dynamic buffers for every task doing i/o).
   However, should the turnaround time exceed 25% of the specified time, or
greater than 100cs when it is automatically controlled, tornado will begin to
warn you that the system is becoming overloaded and you should shut down a
few tasks.
   The only likelihood this will happen is during CPU intensive operations.
You could be using a hires mode without VRAM, and printing multiple files
while moving a lot of windows around will increase the number of processes
exponentially, thus causing cascade overload.
   Obviously, the warning option can be disabled, as multiple warning windows
piling up is just increasing the number of processes, making the situation
worse.

   Another little thing to note is that due to there being two types of
interrupt on Acorn machines - FIQ and IRQ - with one of those virtually
unused as it is too 'strong' - there is little chance to make one interrupt
more 'stronger' than another - which means tornado has to use the same level
of interrupt as more important things like hard discs and the serial port.
Ie; a heavily loaded system may cause tremendous serial access problems
especially, but hopefully hard disc access for most disc controllers will be
unaffected as these aren't so time-critical. It's like running a lot of task
windows while doing serial i/o direct to the HD at high speeds - corruption
occurs (or at least it does on my (older) machine). Preemption relies
intrinsically on interrupts, and while a minimum of code is executed with
interrupts disabled, more switching means more time the computer has no
interrupt servicing abilities ie; the serial port or hard disc can go
unanswered for lengths of time which may cause overruns.


Look
-=-=
   Tornado in look and feel is right up there with the most modern. It uses
true colour throughout, right from window definitions to multi-bitdepth
bitmaps and will render for the current screen being used by the Wimp.
   Obviously, it will work at its best on the later computers with large
amounts of memory, fast hard discs and true colour displays. Unlike RO3.5 it
has built from the bottom to use outline fonts and dithered and textured
backgrounds. Unlike RO3.x, textures show through text, not leaving a blanked
box around each character. Unlike RO3.x, tornado has a considerably enhanced
user interface instead of one which has been built and bodged from the
eighties - things like true-colour graphics, quick-look status and attribute
icons, animation, sound-effects and a common shared set of interface
utilities will ensure it becomes the de facto interface for all platforms.
   While older computers will have the true-colour sprites scaled down to
suit whatever display they're using, newer computers will render them in
their true quality. Animation is used even in little circumstances like the
toggling of a button - instead of the boring inversion from one to the other
extreme, tornado displays a few levels in between depending on user
preferences and/or CPU speed. Sound-bytes can be attached to such switchings,
thus adding a degree of personalisation not heard of before on RISC-OS.
   Thanks to someone on usenet suggesting this, I have decided a common set
of interface utilities would be nice. His idea was to have an extension which
can be replaceable ie; a slider could be replaced with a turnable knob and
the program underneath need never know. These should be fully customisable
and so more personalisation is possible.
   Another suggestion from usenet was multiuser capability. This again will
be managed by tornado, not involving individual applications, and will allow
a user to lock off parts of a hard disc, and have its own preferences for
each application. This extends to startup files and initial displays.

File manager
-=-=-=-=-=-=
   The file manager is a special task which runs under the shell. Its purpose
is to provide management for files, allowing them to be shared between tasks,
and to provide i/o interfaces for/to devices.
   The core of the file manager is interfacing with and manipulating 'data
streams'. Normally, streams of data are piped between different processes by
the shell and multitasker, and can split into two or more seperate streams
at any particular junction. All of this happens automatically, regulated by
the shell.
   The file manager extends the usefulness of these streams greatly. Normally
streams are inter-process only, and never leave RAM or for that matter the
tornado environment. The file manager allows streams to be piped into
physical devices like disc drives, serial ports, printer ports etc.
Therefore, the output of a process can go directly to a printer for printing
(more later).
   Also, it takes the responsibility for the manipulation of files. When a
user drags a file onto a task, the file manager loads it and gives the task a
'view' of the file. At all times, the file is maintained and held by the file
manager.
   However, this is not to say that files cannot be loaded by tasks by
themselves. In such a case, no eye would be present (see below).
   The shell provides hook-ins for the file manager, and essentially they are
part of each other (like Fileswitch and the kernel in RISC-OS). For the
purposes of development they are currently seperate, but may be integrated
together at a later stage.
   As part of the data streaming methodology, icons are added to the title
bar of each window. The first on the right is what owns the window - usually
it will be a mini version of the task's icon. The others indicate what the
direct contents of the window are, what is directly linked to this window
etc. For example: an arrow pointing to a black hat means that the contents of
the window are being fed into a converter. Clicking Menu on these will
produce a small list - for example, the output of the convertor might be
going into another convertor, or might be being spliced off into a viewer, or
temp file, or being printed, or whatever really.
   An open eye represents a view of a file held by the file manager. A closed
eye represents a view of a physical device eg; printer, monitor or keyboard.
So:

-> hat -> hat -> hat -> closed eye
              |
               -> open eye

This would be produced by menu on an arrow and hat on the title bar. However,
an arrow and hat may also be displayed beside a file icon in the filer window
(not easy to do). The file in the filer (say a JPEG) then would be being
converted to a PBM, which is then being converted to a Sprite, which is then
being converted to printer commands, and then sent to the printer to be
printed. However, another tornado application has been asked to view the
Sprite, whether by the user or automatically by tornado (eg; the user
double-clicks on the JPEG file while it is still being printed - rather than
reconvert it, the currently happening conversion is used). In this window, as
the file is converted, the currently converted image is displayed, and is
updated as necessary.
   All of this happens while multi-tasking. The convertors also
multi-process, converting what the previous convertor has processed ie; they
don't wait until the previous process finishes. The converter before the
printer converts the sprite into printer commands, and stores this on disc.
Simulataneously, tornado copies the file, under interrupts, to the printer
(wherever it is). This allows the convertors to print quicker than the
printer can - thus not having processes run longer than necessary.
   BTW, this idea came to me when I was thinking about what Justin Fletcher
said in his docs on the AU cover disc a while back during Irish class - I
still have my notes written into the back of my homework journal! Thanks
Justin!



Hardware requirements
-=-=-=-=-=-=-=-=-=-=-
   Originally, I said that tornado wouldn't need more than a 1Mb floppy-only
Arm2 RO2 machine. This was a long time ago, before tornado even had a
multitasker!
   Now, with the current specification, a minimal usable setup would be 2Mb
20Mb HD RO2 Arm2. This, I stress, is minimal. On such a machine, you would
have limited use as resources would be so stretched.
   However, tornado *will* adapt to its surroundings. It will vary its
multitasking for slower computers, alter its memory usage when memory becomes
tight, and make whatever use of the hard disc(s) available depending on space
free on them and how fast they are.
   Technically speaking, tornado /could/ still work on a 1Mb floppy-only Arm2
RO2 machine, but you wouldn't have any virtual memory, file sharing, and
multitasking would be restricted to say the least. Also, there would be so
little memory available that possibly the only use of tornado in such
circumstances would be as a demo! (and a poor one at that!).
   A more optimal setup would be a 4Mb 100Mb HD RO2 Arm3 machine. On this
machine, tornado's full facilities would be available, although less
effective because of lack of RAM and CPU speed. A fast empty hard disc here
would be ideal as tornado will put little-used buffers and caches onto disc
where possible, stretching to whole or part of files when necessary. This
minimises the RAM required, although it will put a greater load on the CPU.
   The obviously best setup is an infinite memory machine with an ArmX00
series CPU, large fast empty hard disc, and a hires 24 bit display. This
allows tornado to forsake colour, sprite and icon translation and plot
straight into screen memory, making things faster still. The fast CPU allows
a quick turnaround of tasks, with little waste on housekeeping and task
switching code, leaving more for each thread's code. Tornado can also gobble
memory and disable its 'intelligent' memory-saving routines, saving on more
unnecessary code being executed still.