'dual-mode' DefMod

[Tony van der Hoff]

On 25 Apr 2003, in message <cbc37ae84b.Justin at gerph.movspclr.co.uk>,
Justin Fletcher <justin.fletcher at ntlworld.com> wrote:

> Hiya,
> 
> I've put together a version of DefMod which is capable of generating
> 'dual-mode' assembler source files. Basically, this means that rather
> than being forced to create different files - one for apcs26 and one
> for apcs32, it can now generate both as a single source.
> 
> This probably isn't useful for most people.
> 
In truth, DefMod itself isn't useful for many people ;-)

> It's useful for me because the build environment I use requires that
> both 32bit and 26bit libraries be present. As such, building the two
> variants by invoking oslib twice with the same arguments would be... well,
                       ^^^^^ DefMod?
> painful to say the least.

But, that's exactly what I do for the standard build OSLib, which, of course,
provides both environments. It hasn't been a problem so far. Certainly no
pain.

> The fact that it's going to be a 4 hour build really isn't so appealing
> anyhow, but having a single source file for the build is an advantage.
>
I'm confused. I believe that is what we are doing already. Granted that
DefMod is run twice against each swi source, once to generate the o32, and
again to generate the o, and this could arguably do with some tidying up, but
the asm sources it generates (twice) are "bilingual". These source files, two
for each SWI, are not retained or reused, due to their vast number.

It's also true that we generate the s.* and s32.* files, but these are meant
for regression testing, and are not used in the build.

So, I'm not sure what you're achieving, apart from a probably more
elegant solution to generating the two object types. You're probably
gaining a bit on build time, which is neat. At present DefMod invokes the
assembler; presumably in your scheme this is moved to the makefile, which is
also nice, as selecting the assembler one of the bugbears with the DefMod
UNIX port.

However, your figure of 4 hours is a great surprise, unless you're doing
something way out. The standard build, which includes both the 32 bit and the
28 bit libraries, together with the StrongHelp, and the archiving takes 2
hours on my system. That is over a 10B2 network; doing it from a local disc
cuts about 20 minutes from this.

As previously mentioned here, the current major activity is to port the build
to UNIX; this is expected to *dramatically* reduce the build time, so
possibly expending much work on improving the build time under RISC OS could
prove nugatory.
 
> Current tests show that it's working just about sanely, although I've got
> to finish a few bits. In my environment, 32bit objects live in .o32, 26bit
> objects live in .o; again, this may not be ideal, and it isn't suitable
> for use (at this second) with the -viafile option.
> 
Isn't that again what we do in the standard build anyway? Or do you mean you
use UNIX-like extensions?

> Typical use now (for this test) :
> 
[snip]
> 
> I don't know if this is of much interest to you, but I felt it worth
> explaining to you.
> 
It's certainly of interest; as is any contribution to the project; thanks for
explaining it. I'd like some more details, but in principle, I would be quite
happy to put your modifications in the main trunk, once the UNIX port has
been merged back in, provided that Tom and Jonathan agree; do remember that
it will also have to work under UNIX.

> The sources I have based my changes to defmod on are from around mid-march,
> because those just happened to be the sources I had lying around. If much
> has changed, integrating the changes should not be too difficult.
> 
DefMod hasn't changed much for a while now.

-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:www.mk-net.demon.co.uk