[lsb-discuss] appchk - command line processing

Robert Schweikert robert.schweikert at mathworks.com
Fri Jun 29 10:04:59 PDT 2007



Dallman, John wrote:
>> 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.
Yup, library vendors have a big problem. However, I think in the end 
this is the library customers responsibility. As long as the library 
passes appchk (which doesn't check the instructions) the library vendor 
is OK, IMHO. The app vendor has to add the cpuid check somewhere and 
deal with it in an appropriate way. That's easy and maybe we should add 
the 5 lines of assembly to the LSB SDK then ISV's can either link to a 
library or incorporate the check into their app as they see fit.

Robert

-- 
Robert Schweikert                       MAY THE SOURCE BE WITH YOU
(robert.schweikert at mathworks.com)                 LINUX
The MathWorks Inc.
Phone : 508-647-2042






More information about the lsb-discuss mailing list