🚀 go-pugleaf

A hint to the unwary: (That is, people who are still using RISC OS Lib
due to the fact that it infected their programs before they realised how
dangerous it was)...

This is a tip which seems very obvious when you think of it, but which
took about 6 months to occur to me, so it may be helpful to others as well.

It also might help to convince Acorn to produce a version of RISC OS Lib that
has been split into individual functions (or a proper linker) so that
the problem which I am remedying is reduced/removed...
We all knew the problem was bad, but did we realise it was THIS bad?

---

Using LibFile, you can disassemble RISC OS Lib into separate .o files.
This then allows you to remove complete modules from the linking process,
so, for, example, you can replace dbox functions used by your program with
your own code, but still retain the RISC OS Lib interface without the
linker spitting out duplicate definition errors.

Why do this? Well, replacing RISC OS Lib code with your own is much much
easier than changing your whole program to do the same thing through a new
interface. Problems also arise where you are dependant on a deep-rooted
module (e.g. event_ or wimp_) which includes calls to another module, which
includes calls to another module. By replacing the calls that (e.g.) wimp_
makes, you can break that inclusion cycle, and make quite a saving.

By this method you can replace a whole RISC OS Lib module with *just* the
functions which are actually needed/executed by your program.

To show you what a saving you can make, here's a brief burst of very
interesting statistics..

In DSEdit, I have removed the following RISC OS Lib modules, and replaced
them with my own C code with the same interface, including *only* the
functions that DSEdit *uses*. The results of this are:

Library member              code-size   data-size  Comments
o.NotUsed!.bbc                  2228          32   Pulled in by just about
o.bbc                            664           0   every ROLib module...

o.NotUsed!.fileicon              196           0
o.fileicon                       172           0

o.NotUsed!.font                 1972           0   To load templates, you
o.font                            28           0   need font_lose() ONLY

o.NotUsed!.os                   1072           0   Redirected all os functions
o.os                             476           0   through my own SWI interface

o.NotUsed!.sprite               3844           0   ResSpr_ uses sprite_ to
o.sprite                          92           0   init a sprite area and
				----          --   load a sprite file...

Total RISC OS Lib               9312          32
Less total in DSEdit           -1432         - 0
				----          --
Savings:                        7880          32

The NECESSARY code linked in from RISC OS Lib is only about 15% of the total
amount ACTUALLY linked in!

Quite an incredible saving, especially when you consider that NO functionality
has been sacrificed: The program does everything it did before (and in fact
it now does it more efficiently) 

These are just the immediately visible savings - the other thing you get
is increased efficiency, mostly very small, but in some cases to a
quite significant level.

For example:
  In an old version of RISC OS Lib (i.e. I can't vouch for it still being like
  this, but if I had any money I'd be willing to bet that it is), to draw
  a rectangle, you call
    bbc_rectangle

  This in turn calls
    bbc_move (1 call)  and   bbc_plot (4 calls, to draw the lines)

  Now, the bbc_move then calls bbc_plot.

  All the bbc_plots invoked then call:
    os_swi3  (to call SWI "OS_Plot")

  which in turn calls
    os_swi4

  which in turn calls either
    os_swi   or  os_swix

  Whichever of these is called then (I presume) actually calls the SWI!!!

...so if we add all of this up, to draw a rectangle, any program using
RISC OS Lib generates something like *** 16 *** completely redundant
function calls!

I'm all for hiding the low-level interface with higher levels, but isn't
this stretching the point somewhat? ;-)

This may be of little consequence in most places, but in my redraw code (which
uses points and lines somewhat intensively), this equates to a large number
of needlessly wasted CPU cycles...
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)