Ideas for CrissCross
Gonzo
This project is very interesting to me, it fulfills one of my long
sought needs: having a cross platform, open-source, BSD-licensed CPU
detection library. Thanks for the time everyone has put into it.
A couple of ideas and/or questions (I don't want to seem presumptuous
by saying "suggestions"):
* A namespace for the include files: all source code could be under a
directory "crisscross", and code using the library could use "#include
<crisscross/core_cpuid.h>"; this way, there can be no conflict
regarding what file I am referring to.
* A low-level C API: it would be interesting to have a low-level way of
accessing some of the information currently handled by the CoreCPUID
class; the class could, of course, use this low-level API to generate
its own results.
* Textual descriptions for the CPU types: for example, the Linux
utility cpuid in my Ubuntu box says my CPU is an "Intel(R) Pentium(R) M
processor 1.73GHz". Ideally, I would love to find a way to abstract
this information into a data file, and access it from the library, or
maybe automatically generate a piece of C code with all these names;
this way, the same information could be more easily managed and
potentially useful from other apps (I'm thinking of a web page/service
that returns this textual information given the values for the EAX,
EBX, ECX and EDX registers). It might also come in handy if we ever
wanted to provide localized descriptions.
That's all I can think of for now. Of course, I am volunteering to help
with any/all of my ideas if they are considered to be interesting.
Thanks again and best regards,
Gonzo
Steven Noonan
Gonzo wrote:
> Hello,
Hi!
> This project is very interesting to me, it fulfills one of my long
> sought needs: having a cross platform, open-source, BSD-licensed CPU
> detection library. Thanks for the time everyone has put into it.
You're welcome.
> A couple of ideas and/or questions (I don't want to seem presumptuous
> by saying "suggestions"):
>
> * A namespace for the include files: all source code could be under a
> directory "crisscross", and code using the library could use "#include
> <crisscross/core_cpuid.h>"; this way, there can be no conflict
> regarding what file I am referring to.
If you do 'make install', headers will be stored at
/usr/include/crisscross. So this is pretty much already implemented :)
>
> * A low-level C API: it would be interesting to have a low-level way of
> accessing some of the information currently handled by the CoreCPUID
> class; the class could, of course, use this low-level API to generate
> its own results.
Well, this is a C++ project. I don't see it becoming C anytime soon. I
may publish the CoreCPUID under another project if there's enough
demand for it. :)
> * Textual descriptions for the CPU types: for example, the Linux
> utility cpuid in my Ubuntu box says my CPU is an "Intel(R) Pentium(R) M
> processor 1.73GHz". Ideally, I would love to find a way to abstract
> this information into a data file, and access it from the library, or
> maybe automatically generate a piece of C code with all these names;
> this way, the same information could be more easily managed and
> potentially useful from other apps (I'm thinking of a web page/service
> that returns this textual information given the values for the EAX,
> EBX, ECX and EDX registers). It might also come in handy if we ever
> wanted to provide localized descriptions.
I can see why you'd want it to be in a data file (perhaps like
/proc/cpuinfo?), but perhaps you should explain a bit more about this.
As for the processor name, mind that the CPU name it gets is actually
straight from results of a CPUID instruction. I don't have any way of
localizing it. Of course, it's quite possible I'm not reading this
right, so do explain if I'm not getting the point. :)
> That's all I can think of for now. Of course, I am volunteering to help
> with any/all of my ideas if they are considered to be interesting.
>
> Thanks again and best regards,
>
> Gonzo
Thank you, too.
- Steven
Gonzo
> > directory "crisscross", and code using the library could use "#include
> > <crisscross/core_cpuid.h>"; this way, there can be no conflict
> > regarding what file I am referring to.
>
> If you do 'make install', headers will be stored at
> /usr/include/crisscross. So this is pretty much already implemented :)
Ah, ok. Although it would be even nicer if this was available while
working on crisscross (I mean, when compiling on the directory checked
out from the svn repo).
> > * A low-level C API: it would be interesting to have a low-level way of
> > accessing some of the information currently handled by the CoreCPUID
> > class; the class could, of course, use this low-level API to generate
> > its own results.
>
> Well, this is a C++ project. I don't see it becoming C anytime soon. I
> may publish the CoreCPUID under another project if there's enough
> demand for it. :)
I was thinking along the lines of having one (or maybe two, whatever is
best) C functions that simply returned all the information gathered
with CPUID. I have the feeling that this would make it easier to
integrate crisscross into other environments that lend themselves to be
extended via C (not C++) calls. For example, if you wanted to make the
CPUID functionality available to Ruby, Perl, PHP, etc.
> > * Textual descriptions for the CPU types: for example, the Linux
> > utility cpuid in my Ubuntu box says my CPU is an "Intel(R) Pentium(R) M
> > processor 1.73GHz". Ideally, I would love to find a way to abstract
> > this information into a data file, and access it from the library, or
> > maybe automatically generate a piece of C code with all these names;
> > this way, the same information could be more easily managed and
> > potentially useful from other apps (I'm thinking of a web page/service
> > that returns this textual information given the values for the EAX,
> > EBX, ECX and EDX registers). It might also come in handy if we ever
> > wanted to provide localized descriptions.
>
> I can see why you'd want it to be in a data file (perhaps like
> /proc/cpuinfo?), but perhaps you should explain a bit more about this.
> As for the processor name, mind that the CPU name it gets is actually
> straight from results of a CPUID instruction. I don't have any way of
> localizing it. Of course, it's quite possible I'm not reading this
> right, so do explain if I'm not getting the point. :)
When you look at sources such as this:
http://www.sandpile.org/ia32/cpuid.htm
you realize there is a lot of information (more or less standardized)
that can be printed given the results of CPUID. For example, for my
laptop's CPU you can actually deduce the following description:
Pentium M Dothan (0.09 um) with 512/2048 KB on-die L2 cache
All this information could be handled in a table (perhaps stored in a
flat text file) so that, given the results of CPUID, you can build the
detailed CPU name.
Best regards,
Gonzo
Steven Noonan
Gonzo wrote:
> > If you do 'make install', headers will be stored at
> > /usr/include/crisscross. So this is pretty much already implemented :)
>
> Ah, ok. Although it would be even nicer if this was available while
> working on crisscross (I mean, when compiling on the directory checked
> out from the svn repo).
Yeah, I discovered this, along with another unexpected problem during
the post-0.5.1 testing. I'll be fixing it very soon and then releasing
v0.5.2, which will have that fixed.
> > Well, this is a C++ project. I don't see it becoming C anytime soon. I
> > may publish the CoreCPUID under another project if there's enough
> > demand for it. :)
>
> I was thinking along the lines of having one (or maybe two, whatever is
> best) C functions that simply returned all the information gathered
> with CPUID. I have the feeling that this would make it easier to
> integrate crisscross into other environments that lend themselves to be
> extended via C (not C++) calls. For example, if you wanted to make the
> CPUID functionality available to Ruby, Perl, PHP, etc.
You're welcome to use the CoreCPUID code if you wish, and write a C
library for it. But this is a C++ project, and is designed in an
object-oriented manner.
> > I can see why you'd want it to be in a data file (perhaps like
> > /proc/cpuinfo?), but perhaps you should explain a bit more about this.
> > As for the processor name, mind that the CPU name it gets is actually
> > straight from results of a CPUID instruction. I don't have any way of
> > localizing it. Of course, it's quite possible I'm not reading this
> > right, so do explain if I'm not getting the point. :)
>
> When you look at sources such as this:
>
> http://www.sandpile.org/ia32/cpuid.htm
>
> you realize there is a lot of information (more or less standardized)
> that can be printed given the results of CPUID. For example, for my
> laptop's CPU you can actually deduce the following description:
>
> Pentium M Dothan (0.09 um) with 512/2048 KB on-die L2 cache
>
> All this information could be handled in a table (perhaps stored in a
> flat text file) so that, given the results of CPUID, you can build the
> detailed CPU name.
Yeah, you could actually whip up a quick CrissCross application to do
that, and use the TextWriter or CoreConsole (depending on whether you
want to write to a file or stdout) class to output the data in any
format you want.
- Steven