* [9fans] arch specific executables
@ 2010-01-25 14:35 erik quanstrom
2010-01-25 14:57 ` Lyndon Nerenberg
2010-01-25 16:08 ` Steve Simon
0 siblings, 2 replies; 12+ messages in thread
From: erik quanstrom @ 2010-01-25 14:35 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 14:35 [9fans] arch specific executables erik quanstrom
@ 2010-01-25 14:57 ` Lyndon Nerenberg
2010-01-25 17:51 ` erik quanstrom
2010-01-25 16:08 ` Steve Simon
1 sibling, 1 reply; 12+ messages in thread
From: Lyndon Nerenberg @ 2010-01-25 14:57 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 14:35 [9fans] arch specific executables erik quanstrom
2010-01-25 14:57 ` Lyndon Nerenberg
@ 2010-01-25 16:08 ` Steve Simon
2010-01-25 17:08 ` Charles Forsyth
1 sibling, 1 reply; 12+ messages in thread
From: Steve Simon @ 2010-01-25 16:08 UTC (permalink / raw)
To: 9fans
> i have a little program, aux/cpuid
perhaps this would be better in /dev/cons/cpuid ?
just my 2¢
-Steve
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 16:08 ` Steve Simon
@ 2010-01-25 17:08 ` Charles Forsyth
2010-01-25 17:32 ` Lyndon Nerenberg
2010-01-25 17:54 ` erik quanstrom
0 siblings, 2 replies; 12+ messages in thread
From: Charles Forsyth @ 2010-01-25 17:08 UTC (permalink / raw)
To: 9fans
>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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 17:08 ` Charles Forsyth
@ 2010-01-25 17:32 ` Lyndon Nerenberg
2010-01-25 17:54 ` erik quanstrom
1 sibling, 0 replies; 12+ messages in thread
From: Lyndon Nerenberg @ 2010-01-25 17:32 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 14:57 ` Lyndon Nerenberg
@ 2010-01-25 17:51 ` erik quanstrom
2010-01-25 18:13 ` Lyndon Nerenberg
2010-01-27 11:26 ` Ethan Grammatikidis
0 siblings, 2 replies; 12+ messages in thread
From: erik quanstrom @ 2010-01-25 17:51 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 17:08 ` Charles Forsyth
2010-01-25 17:32 ` Lyndon Nerenberg
@ 2010-01-25 17:54 ` erik quanstrom
2010-01-25 18:10 ` ron minnich
1 sibling, 1 reply; 12+ messages in thread
From: erik quanstrom @ 2010-01-25 17:54 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 17:54 ` erik quanstrom
@ 2010-01-25 18:10 ` ron minnich
2010-01-25 18:21 ` erik quanstrom
0 siblings, 1 reply; 12+ messages in thread
From: ron minnich @ 2010-01-25 18:10 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 17:51 ` erik quanstrom
@ 2010-01-25 18:13 ` Lyndon Nerenberg
2010-01-27 11:26 ` Ethan Grammatikidis
1 sibling, 0 replies; 12+ messages in thread
From: Lyndon Nerenberg @ 2010-01-25 18:13 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> x86 assembly doesn't often assemble with an
> arm assembler. :-)
Oh come on. Everything you need to make this work is already there.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 18:10 ` ron minnich
@ 2010-01-25 18:21 ` erik quanstrom
0 siblings, 0 replies; 12+ messages in thread
From: erik quanstrom @ 2010-01-25 18:21 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-25 17:51 ` erik quanstrom
2010-01-25 18:13 ` Lyndon Nerenberg
@ 2010-01-27 11:26 ` Ethan Grammatikidis
2010-01-27 13:01 ` erik quanstrom
1 sibling, 1 reply; 12+ messages in thread
From: Ethan Grammatikidis @ 2010-01-27 11:26 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] arch specific executables
2010-01-27 11:26 ` Ethan Grammatikidis
@ 2010-01-27 13:01 ` erik quanstrom
0 siblings, 0 replies; 12+ messages in thread
From: erik quanstrom @ 2010-01-27 13:01 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-01-27 13:01 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-25 14:35 [9fans] arch specific executables erik quanstrom
2010-01-25 14:57 ` Lyndon Nerenberg
2010-01-25 17:51 ` erik quanstrom
2010-01-25 18:13 ` Lyndon Nerenberg
2010-01-27 11:26 ` Ethan Grammatikidis
2010-01-27 13:01 ` erik quanstrom
2010-01-25 16:08 ` Steve Simon
2010-01-25 17:08 ` Charles Forsyth
2010-01-25 17:32 ` Lyndon Nerenberg
2010-01-25 17:54 ` erik quanstrom
2010-01-25 18:10 ` ron minnich
2010-01-25 18:21 ` erik quanstrom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).