Re: [9fans] arch specific executables
On 25 Jan 2010, at 5:51 pm, erik quanstrom wrote: On Mon Jan 25 10:00:19 EST 2010, lyn...@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 eeke...@fastmail.fm
Re: [9fans] arch specific executables
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
Re: [9fans] arch specific executables
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
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
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
On Mon Jan 25 10:00:19 EST 2010, lyn...@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
On Mon Jan 25 12:03:08 EST 2010, fors...@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 0x8005 # cache sizes ff08ff08 ff20ff20 40020140 40020140 - erik
Re: [9fans] arch specific executables
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
On Mon Jan 25 13:11:49 EST 2010, rminn...@gmail.com wrote: On Mon, Jan 25, 2010 at 9:54 AM, erik quanstrom quans...@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 0x8005 # 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
