[lsb-discuss] appchk - command line processing

Dallman, John jgd at ugs.com
Fri Jun 29 09:54:00 PDT 2007


> Robert Schweikert wrote: 
> > Nick Stoughton wrote:

> > The IA32 spec says, in 8.1.1, "Only the features of the Intel486
> > processor instruction set may be assumed to be present. An 
> > application should determine if any additional instruction set 
> > features are available before using those additional features. 
> > If a feature is not present, then a conforming application shall 
> > not use it."

> I think the LSB should provide a mechanism for ISVs to restrict the 
> instruction set, such as "Our app only runs on P4 and better" 
> and still be LSB compliant. 

I'm with you there. We currently document the processors that 
we know work; currently, this comes out as Intel and AMD i686 
and up for 32-bit code, and any x86-64 for 64-bit code. 

Given the real hardware that people use for running apps, changing
the LSB spec to require i686 would be one course of action. If the
LSB feels it has to provide universal binary support down onto 
low-end embedded systems - which are what 486s get used for these 
days, to the best of my knowledge - then there has to be a way to 
avoid crippling code that needs a better processor to run at a 
usable speed. 

And Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:

> The original intention was that users running programs on 
> inadequate processors should not be greeted with
> 
> Illegal instruction (core dumped)
> 
> or wrong results.
> 
> If the app runs in the sense of
> 
> --
> $ frobology
> Frobology 1.5 requires a processor with MMX instructions
> $
> --
> that was intended to be "compliant"

That makes perfectly good sense for code where there's a 
discernable and reasonably small "processing core" that 
can be provided in several versions, and there is much 
surrounding code that is not even slightly performance 
critical. However, that's simply not the case for the 
stuff we do, and since it's a library, rather than an 
application, there isn't a trivial way of checking. We 
just stick the whole thing through the compiler with the 
required processor settings: there's no question of asm 
code or anything like that, since the same source has to 
build on loads of platforms. 

Frankly, saying "you must run on 486 enough to say that 
you need something better" isn't something that ISVs are 
going to be very interested in. We see no, as in zero, 
customer-led demand for LSB; we use it strictly for our 
own convenience. If that means we have to switch from 
saying "it's LSB-compliant" to "It is built using LSB tools
and would be LSB compliant but for the fact that it uses 
instruction set that is 12, rather than 17, years old", 
we'd just do that. 

-- 
John Dallman
Parasolid Porting Engineer




More information about the lsb-discuss mailing list