🚀 go-pugleaf

In article <41gl19$j8p@seagoon.newcastle.edu.au>
           peter@tesla.newcastle.edu.au "Peter Moylan" writes:

> [Background: we're talking here about the problem of including
> CPU-specific code in TopSpeed assembler.  The problem is: is there
> any mechanism in the TopSpeed project system that will let us use
> assembler conditionals that check which processor model the project
> is being compiled for; that is, is there any way to read back the
> current setting of the "optimize" pragma?]
> 
> Martin Tom Brown (Martin@nezumi.demon.co.uk) wrote:
> 
> >I think I know how to do what you want, but it isn't pretty, and opens
> >up the potential black hole of code compiled for a higher CPU model,
> >but with the same library names as the original standard models. 
> 
> >Edit TSPRJ.TXT
> >       add somewhere near the #pragma optimise(cpu=>86) 
> >       
> >               #pragma define (_mycpu486=>on)
> 
> >       (nested so that it is set appropriately)
> 
> [Further details given in the original posting]
 
> My first reaction was to think that this would work, but after
> looking at TSPRJ.TXT I'd say that it probably won't.  The
> #pragma optimise referred to above is embedded inside some
> conditional tests, and it all boils down to saying something
> like "if the environment is OS/2 or Windows or DOS Extender,
> then assume that we have a fancier model of the processor".

Sadly you are right, I only had a quick look and thought I had
found the right place to change. Oops!
You could still define your own memory model to set _mycpu486

> Note in any case that TSPRJ.TXT is merely setting up defaults
> for the pragma settings.  If there's a #pragma optimise in the
> user's project file - and there often is - then that will
> override the settings made by TSPRJ.TXT.

We need to find the token name that the optimize cpu setting
can be accessed from (if any). I suspect only the compilers 
have access to these values, so we may well be stuck. 
 
> The end result will be that _mycpu486 will depend on the
> operating system, not on the processor.

> I'm still convinced that there's something in the project system
> which allows the current value of "cpu" to be interrogated.
> I've tried some of the more obvious possibilities, but with no
> luck so far.

I'd also be interested to know. It isn't so much of a problem for me.
I can safely assume a minimum of 486 for almost all my own work,
and I don't have to ensure backwards compatibility to 80x86, x<3.
After all they would have a *really* tough time running OS/2!

Best regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/