[9fans] arch specific executables

[9fans] arch specific executables

[erik quanstrom]

i have a little program, aux/cpuid, that gets cpuid
information for x86 processors.  clearly it's not going
to run on an arm or mips.  is there a standard
trick for preventing such a program from being
built (and failing)?  the hack i currently have is
objtype=386 as the first line of the mkfile.

- erik

Re: [9fans] arch specific executables

[Lyndon Nerenberg]

> i have a little program, aux/cpuid, that gets cpuid
> information for x86 processors.  clearly it's not going
> to run on an arm or mips.  is there a standard
> trick for preventing such a program from being
> built (and failing)?  the hack i currently have is
> objtype=386 as the first line of the mkfile.

Why not make it build everywhere and have it print a diagnostic for
platforms it doesn't support. E.g.

   $CC -Darch=''''$objtype'''' ...

(I doubt the quoting is correct, but you get the idea.)

and

   int arch;
     .
     .
     .
   switch arch {

   default: fprint(2, "unknown $objtype\n");
            exits("unknown arch"); break;

   'k': fprint(2, "unsupported architecture\n");
        exits("unsupported arch"); break;
     .
     .
     .
   '8': cpuid();
        break;
   }

This way is can embrace new platforms over time.

--lyndon

Re: [9fans] arch specific executables

[Steve Simon]

> i have a little program, aux/cpuid

perhaps this would be better in /dev/cons/cpuid ?

just my 2¢

-Steve

Re: [9fans] arch specific executables

[Charles Forsyth]

>perhaps this would be better in /dev/cons/cpuid ?

doppio% ls '#P'
'#P/archctl'
'#P/cputype'
'#P/ioalloc'
'#P/iob'
'#P/iol'
'#P/iow'
'#P/irqalloc'
'#P/realmode'
'#P/realmodemem'

doppio% cat '#P/cputype'
AMD64 1802

doppio% cat '#P/archctl'
cpu AMD64 1802 pge
pge on
coherence mb586
cmpswap cmpswap486
i8253set on

Re: [9fans] arch specific executables

[Lyndon Nerenberg]

> doppio% cat '#P/archctl'

Isn't archctl more concerned with things specifically of interest to the
kernel vm system? That was always my impression. Adding CPUID related
output to #P/cputype seems more logical.

Re: [9fans] arch specific executables

[erik quanstrom]

On Mon Jan 25 10:00:19 EST 2010, lyndon@orthanc.ca wrote:
> > i have a little program, aux/cpuid, that gets cpuid
> > information for x86 processors.  clearly it's not going
> > to run on an arm or mips.  is there a standard
> > trick for preventing such a program from being
> > built (and failing)?  the hack i currently have is
> > objtype=386 as the first line of the mkfile.
>
> Why not make it build everywhere and have it print a diagnostic for
> platforms it doesn't support. E.g.

x86 assembly doesn't often assemble with an
arm assembler.  :-)

- erik

Re: [9fans] arch specific executables

[erik quanstrom]

On Mon Jan 25 12:03:08 EST 2010, forsyth@terzarima.net wrote:
> >perhaps this would be better in /dev/cons/cpuid ?

i don't think so.

> doppio% cat '#P/cputype'
> AMD64 1802
>
> doppio% cat '#P/archctl'
> cpu AMD64 1802 pge
> pge on
> coherence mb586
> cmpswap cmpswap486
> i8253set on

none of that was what i was looking for.  i needed the
cpuid family, model, and stepping info.  it's not available
in '#P' and i didn't want to reboot.  also, the vendor
string is helpful and seems silly to add to the kernel.

; aux/cpuid -v
AuthenticAMD
; aux/cpuid -b
AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
; aux/cpuid -s
00060fb2 0f.6b.02
; 8.cpuid -n 0x80000005	# cache sizes
ff08ff08 ff20ff20 40020140 40020140

- erik

Re: [9fans] arch specific executables

[ron minnich]

On Mon, Jan 25, 2010 at 9:54 AM, erik quanstrom <quanstro@quanstro.net> wrote:

> ; aux/cpuid -v
> AuthenticAMD
> ; aux/cpuid -b
> AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
> ; aux/cpuid -s
> 00060fb2 0f.6b.02
> ; 8.cpuid -n 0x80000005 # cache sizes
> ff08ff08 ff20ff20 40020140 40020140

All of this stuff is available via cpuid, including the string. I
think the kernel device is the logical place to put it. Maybe I'm
misunderstanding however.

ron

Re: [9fans] arch specific executables

[Lyndon Nerenberg]

> x86 assembly doesn't often assemble with an
> arm assembler.  :-)

Oh come on. Everything you need to make this work is already there.

Re: [9fans] arch specific executables

[erik quanstrom]

On Mon Jan 25 13:11:49 EST 2010, rminnich@gmail.com wrote:
> On Mon, Jan 25, 2010 at 9:54 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>
> > ; aux/cpuid -v
> > AuthenticAMD
> > ; aux/cpuid -b
> > AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
> > ; aux/cpuid -s
> > 00060fb2 0f.6b.02
> > ; 8.cpuid -n 0x80000005 # cache sizes
> > ff08ff08 ff20ff20 40020140 40020140
>
> All of this stuff is available via cpuid, including the string. I
> think the kernel device is the logical place to put it. Maybe I'm
> misunderstanding however.

that's what i did.  from user mode.  there are no
magic strings in the executable.  see contrib quanstro/cpuid.
no man page.  no time today.

- erik

Re: [9fans] arch specific executables

[Ethan Grammatikidis]

On 25 Jan 2010, at 5:51 pm, erik quanstrom wrote:

> On Mon Jan 25 10:00:19 EST 2010, lyndon@orthanc.ca wrote:
>>> i have a little program, aux/cpuid, that gets cpuid
>>> information for x86 processors.  clearly it's not going
>>> to run on an arm or mips.  is there a standard
>>> trick for preventing such a program from being
>>> built (and failing)?  the hack i currently have is
>>> objtype=386 as the first line of the mkfile.
>>
>> Why not make it build everywhere and have it print a diagnostic for
>> platforms it doesn't support. E.g.
>
> x86 assembly doesn't often assemble with an
> arm assembler.  :-)
>
> - erik
>

Heh. :)

P9P uses a separate file for each arch: plan9/src/libthread/$os-$arch.s

Inferno uses a separate dir. Some of the dirs have C code instead
since the asm is only an optimisation in this case.

I'd put a test in the mkfile: if cpuid-$objtype exists build that,
else.. well, either error out or build cpuid-port.c which in turn
either emits an error at runtime or perhaps more usefully outputs the
contents of #P/cputype.


--
http://xkcd.com/676/

Ethan Grammatikidis
eekee57@fastmail.fm

Re: [9fans] arch specific executables

[erik quanstrom]

> Heh. :)
>
> P9P uses a separate file for each arch: plan9/src/libthread/$os-$arch.s
>
> Inferno uses a separate dir. Some of the dirs have C code instead
> since the asm is only an optimisation in this case.
>
> I'd put a test in the mkfile: if cpuid-$objtype exists build that,
> else.. well, either error out or build cpuid-port.c which in turn
> either emits an error at runtime or perhaps more usefully outputs the
> contents of #P/cputype.

all these examples either have a portable way of doing $function
or they implement it for each architecture.  i suppose one could
add arm support.  but at this point, i don't have any intention of
doing so.  be glad to take the code, though.

- erik