🚀 go-pugleaf

In article <40tvub$in9@seagoon.newcastle.edu.au>
           peter@tesla.newcastle.edu.au "Peter Moylan" writes:

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

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. 

Try this at your own risk and backup the original files first!
I have only tried it quickly on TS v3.02 for OS/2 - seems OK.
But I haven't tested it beyond a quick look see...

Edit TSPRJ.TXT
	add somewhere near the #pragma optimise(cpu=>86) 
	
		#pragma define (_mycpu486=>on)

	(nested so that it is set appropriately)

Then run TSCFG.EXE to rebuild TSPRJ.TXT file into the TS DLL's,
so that the compiler/pragma mechanism exports "_mycpu486".

Edit CORELIB.INC
	add the line:

		Use486 = _mycpu486

You can now edit any sources which use  CORELIB.INC and use the

	(*%T Use486*)
		<486 specific code>
	(*%E*)

Construct as requested. The problem is that the linker has no way
of knowing that the libraries you build now have 486 code in them
but use the same names as the original '86 generic versions.

It might even be possible with some careful thought to modify the
TSPRJ.TXT to generate distinct libraries by CPUtype as well. I 
haven't looked at that but it would be nice if that were possible.

No guarantees that it works exactly as described, but this forms
the basis of how to pass compiler info down to assembler files.
You need the sources to do this. Anyway hope it helps. Good luck!

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