🚀 go-pugleaf

Mark Morgan Lloyd (mark_tbu@cix.compulink.co.uk) wrote:

>I would have thought it would have been better to determine the type of 
>CPU at runtime, either by having a global variable that the assembler 
>code checks or by building a table containing the entry points during 
>initialisation.

But by then it's too late.  The most common reason for wanting to
write CPU-specific code is that you want to write something like

    IF we have an advanced-model CPU THEN
         use the more efficient code sequence
    ELSE
         execute code that's less efficient but more portable
    ENDIF

This makes sense if the IF represents a compile-time decision.
If it's a run-time decision, you've lost the speed advantage by
having to make the run-time test.  You've also lost the code
compactness, which might well have been the motivation for using
the "advanced" CPU instructions in the first place.

>Remember that if CPU-specific code is built, it may cause problems on 
>multi-CPU systems, e.g. a '386 with a '186 as an I/O processor.

True ... but it depends on the form in which the software is
distributed.  If you distribute binary compiled modules, then of
course you have to provide a version for every supported scenario.
If you distribute source code, you simply ask the user to
compile with the right compile-time options set.  You could set
different options for different modules.

I have a problem like this with my PMOS library, which contains
a small number of assembly language modules.  So far I've chosen
to specify that the processor be an 80186 or better, because
I don't want to cripple my code just for the sake of the
relatively few number of potential users who have only an 8086
or 8088.  But I'd much prefer to put in conditional assembly
directives that covered all possibilities.  It's frustrating:
the TopSpeed pragma system clearly has something that lets you
specify the processor model, but there doesn't seem to be any
way to access this feature in assembly code.  (More likely, there
is such a way, but it's undocumented.)

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           file://ee.newcastle.edu.au/pub/www/Moylan.html