🚀 go-pugleaf

> 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

I was thinking along the lines of:


MODULE DemoModule;

VAR     cpuSpecificProc: PROC;


PROCEDURE is386(): BOOLEAN;

BEGIN
END is386;


PROCEDURE optimisedFor386;

BEGIN
END optimisedFor386;


PROCEDURE optimisedForNot386;

BEGIN
END optimisedForNot386;


PROCEDURE goDoStuff;

BEGIN
  cpuSpecificProc
END goDoStuff


(* Module initialisation.                                       *)

BEGIN
  IF is386() THEN
    cpuSpecificProc:= optimisedFor386
  ELSE
    cpuSpecificProc:= optimisedForNot386
  END;
  goDoStuff
END DemoModule.


Alternatively, DLL model with different parameters to LoadModule() (or 
whatever it's called- I'm working from memory here). In both cases, the 
time lost is that required to make an indirect call, also there is a 
handicap of not being able to specify the code INLINE.

> 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.

Ouch. Shrouded Modula-2? :-)

>  (More likely, there
> is such a way, but it's undocumented.)

An informed source told me that it takes a week to teach new staff at 
TopSpeed (or whatever they call themselves now) the intricacies of the 
build mechanism. We're coming up to a long weekend here, and if I can 
catch him I'll ask if he knows anything about this... among other things 
he was responsible for the TopSpeed interfaces to third-party libraries.

Mark Morgan Lloyd
mark_tbu@cix.compulink.co.uk

[Opinions above are the author's, not those of his employers or 
colleagues]

P.S. May be dropping out of this newsgroup for a while, until the 
cross-postings die down.