www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - core.cpuid

reply Manu <turkeyman gmail.com> writes:
What's the deal with core.cpuid?
I realise it is an x86 opcode, but is that something that you really want
totally bare in core like that?
I'm experimenting with other architectures, and some sort of
core.processorInfo would be really nice, surely an API for this stuff should
be more generalised...?
Oct 29 2011
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-10-2011 02:49, Manu wrote:

 What's the deal with core.cpuid?
 I realise it is an x86 opcode, but is that something that you really
 want totally bare in core like that?
 I'm experimenting with other architectures, and some sort of
 core.processorInfo would be really nice, surely an API for this stuff
 should be more generalised...?


That module was probably designed around the assumption that D would 
never run on !x86 architectures, which is clearly not the case with GDC 
existing...

- Alex
Oct 29 2011
parent reply Manu <turkeyman gmail.com> writes:
Seems like a horrible assumption to make when inventing a systems
programming language that intends to go head to head with C/C++ :)

On 30 October 2011 03:51, Alex R=C3=B8nne Petersen <xtzgzorex gmail.com> wr=
ote:


 On 30-10-2011 02:49, Manu wrote:


 What's the deal with core.cpuid?
 I realise it is an x86 opcode, but is that something that you really
 want totally bare in core like that?
 I'm experimenting with other architectures, and some sort of
 core.processorInfo would be really nice, surely an API for this stuff
 should be more generalised...?


 That module was probably designed around the assumption that D would neve=


r

 run on !x86 architectures, which is clearly not the case with GDC
 existing...

 - Alex
Oct 29 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Manu wrote:


 Seems like a horrible assumption to make when inventing a systems
 programming language that intends to go head to head with C/C++ :)
 


FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie. 
developers rarely use cpuid.h directly). You should not (in practice) use 
"core" modules anyway.
Nov 04 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 04, 2011 08:11 Dejan Lekic wrote:

 Manu wrote:

 Seems like a horrible assumption to make when inventing a systems
 programming language that intends to go head to head with C/C++ :)


 
 FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie.
 developers rarely use cpuid.h directly). You should not (in practice) use
 "core" modules anyway.


And why not? Thread is in core. So are other modules that it's perfectly 
normal and acceptable to use. There's nothing wrong with using core modules. 
Many of them are _intended_ to be used. Stuff generally ends up in core 
because the D runtime needs it, not because it's something that the common 
programmer shouldn't be using.

- Jonathan M Davis
Nov 04 2011
next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Jonathan M Davis wrote:


 
 And why not? Thread is in core. So are other modules that it's perfectly


- Mostly because You may end-up writing non-portable code unless you are 
realy careful (and you must be if you use core modules! ;). It is similar to 
the asm{} block - you should not use it at all unless you know what you are 
doing... Does that make sense?
Nov 04 2011
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 04, 2011 10:39 Dejan Lekic wrote:

 Jonathan M Davis wrote:

 And why not? Thread is in core. So are other modules that it's perfectly


 
 - Mostly because You may end-up writing non-portable code unless you are
 realy careful (and you must be if you use core modules! ;). It is similar
 to the asm{} block - you should not use it at all unless you know what you
 are doing... Does that make sense?


Plenty of core is portable. True, very little in Phobos is non-portable, so 
there's less risk of portability issues with Phobos, but much of druntime is 
quite portable - Thread being one such example. It's primarily the C 
declarations which aren't necessarily portable. Most of the D code is.

Now, it _is_ ultimately to the programmer to be smart about what they're 
doing, and more stuff in druntime is non-portable than in Phobos, but it's 
generally pretty clear about what's portable and what isn't. I really don't 
think that there's any need to tell people to stay away from core. If 
anything, they'll stay often away from it simply because much of its 
functionality is not directly necessary (if necessary at all) in your average 
program. But if you need it, there's nothing wrong with using it, and on the 
whole, portability isn't a huge issue.

- Jonathan M Davis
Nov 04 2011
prev sibling parent Don <nospam nospam.com> writes:
On 04.11.2011 18:27, Jonathan M Davis wrote:

 On Friday, November 04, 2011 08:11 Dejan Lekic wrote:

 Manu wrote:

 Seems like a horrible assumption to make when inventing a systems
 programming language that intends to go head to head with C/C++ :)


 FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie.
 developers rarely use cpuid.h directly). You should not (in practice) use
 "core" modules anyway.


 And why not? Thread is in core. So are other modules that it's perfectly
 normal and acceptable to use. There's nothing wrong with using core modules.
 Many of them are _intended_ to be used. Stuff generally ends up in core
 because the D runtime needs it, not because it's something that the common
 programmer shouldn't be using.


That's largely true, but I would agree with Manu that you shouldn't be 
using core very often. By its nature of being close to the runtime, it's 
typically low-level stuff, and so it's only your low-level code which 
should be using it.

Probably there is some stuff in there which should be moved out of core, 
or possibly with a safer wrapper in std. I'm particularly thinking of 
core.bitop, which currently has a mixture of safe and subtly dangerous 
functions, and only a small part of it is actually required by the runtime.
Nov 04 2011
prev sibling next sibling parent reply "Chante" <udontspamme never.will.u> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...


 What's the deal with core.cpuid?


I think they just want the "mainstream" 
("sheeple"/"followers"/"believers"/"90210_ers"/"younsters", etc.). If you 
don't fit into their petri-dish and aren't cog to add to their 
self-aggrandizement, they won't let you log in anymore.
Oct 29 2011
parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Sat, Oct 29, 2011 at 10:55 PM, Chante <udontspamme never.will.u> wrote:


 "Manu" <turkeyman gmail.com> wrote in message
 news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...


 What's the deal with core.cpuid?


 I think they just want the "mainstream"
 ("sheeple"/"followers"/"believers"/"90210_ers"/"younsters", etc.). If you
 don't fit into their petri-dish and aren't cog to add to their
 self-aggrandizement, they won't let you log in anymore.


There are a few things like this around, and if you look far enough back,
it's quite simple why things like this happened. Originally, when D was
new, DMD essentially was the definition of D, x86 was the only real
architecture around, with x86_64 starting to come into play. Now we have
more compilers, and x86/64 isn't looking quite like the monopoly it used to
be, so this interface will probably need to change.

There's no conspiracy here, it's just "what worked" back in the day, and
either it's unused or unimportant such that no one has tried to update it
thus far. Since this is in core, it's mostly Sean's territory, but I'm sure
he'd welcome ideas.
Oct 29 2011
next sibling parent "Chante" <udontspamme never.will.u> writes:
"Andrew Wiley" <wiley.andrew.j gmail.com> wrote in message 
news:mailman.591.1319951129.24802.digitalmars-d puremagic.com...

 On Sat, Oct 29, 2011 at 10:55 PM, Chante <udontspamme never.will.u> 
 wrote:


 "Manu" <turkeyman gmail.com> wrote in message
 news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...


 What's the deal with core.cpuid?


 I think they just want the "mainstream"
 ("sheeple"/"followers"/"believers"/"90210_ers"/"younsters", etc.). If 
 you
 don't fit into their petri-dish and aren't cog to add to their
 self-aggrandizement, they won't let you log in anymore.


 There are a few things like this around, and if you look far enough 
 back,
 it's quite simple why things like this happened. Originally, when D was
 new, DMD essentially was the definition of D, x86 was the only real
 architecture around, with x86_64 starting to come into play. Now we 
 have
 more compilers, and x86/64 isn't looking quite like the monopoly it 
 used to
 be, so this interface will probably need to change.

 There's no conspiracy here, it's just "what worked" back in the day, 
 and
 either it's unused or unimportant such that no one has tried to update 
 it
 thus far. Since this is in core, it's mostly Sean's territory, but I'm 
 sure
 he'd welcome ideas.


I didn't call you anything.
Oct 30 2011
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 30-10-2011 06:05, Andrew Wiley wrote:

 On Sat, Oct 29, 2011 at 10:55 PM, Chante <udontspamme never.will.u> wrote:


     "Manu" <turkeyman gmail.com <mailto:turkeyman gmail.com>> wrote in
     message
     news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...

      > What's the deal with core.cpuid?

     I think they just want the "mainstream"
     ("sheeple"/"followers"/"believers"/"90210_ers"/"younsters", etc.).
     If you
     don't fit into their petri-dish and aren't cog to add to their
     self-aggrandizement, they won't let you log in anymore.



 There are a few things like this around, and if you look far enough
 back, it's quite simple why things like this happened. Originally, when
 D was new, DMD essentially was the definition of D, x86 was the only
 real architecture around, with x86_64 starting to come into play. Now we
 have more compilers, and x86/64 isn't looking quite like the monopoly it
 used to be, so this interface will probably need to change.

 There's no conspiracy here, it's just "what worked" back in the day, and
 either it's unused or unimportant such that no one has tried to update
 it thus far. Since this is in core, it's mostly Sean's territory, but
 I'm sure he'd welcome ideas.


I actually do use core.cpuid and find it very useful.

I think what we need to do is have separate modules for the various 
architectures, and then have some central wrapper module that wraps the 
common stuff that most archs share (i.e. "are we using 64-bit 
pointers?", etc...). We still need to keep the modules with more 
arch-specific checks public, because someone might actually need to use 
that information (in my case, I need it to decide which instructions I 
can emit in my JIT compiler).

Speaking of all this, we really need to standardize version identifiers 
for !x86 architectures in the web site...

- Alex
Oct 30 2011
parent "Chante" <udontspamme never.will.u> writes:
Alex Rønne Petersen wrote:

 On 30-10-2011 06:05, Andrew Wiley wrote:

 On Sat, Oct 29, 2011 at 10:55 PM, Chante <udontspamme never.will.u>
 wrote: "Manu" <turkeyman gmail.com <mailto:turkeyman gmail.com>> wrote
     in message
     news:mailman.586.1319935753.24802.digitalmars-d puremagic.com...

      > What's the deal with core.cpuid?

     I think they just want the "mainstream"
     ("sheeple"/"followers"/"believers"/"90210_ers"/"younsters",
     etc.). If you
     don't fit into their petri-dish and aren't cog to add to their
     self-aggrandizement, they won't let you log in anymore.



 There are a few things like this around, and if you look far enough
 back, it's quite simple why things like this happened. Originally,
 when D was new, DMD essentially was the definition of D, x86 was the 
 only
 real architecture around, with x86_64 starting to come into play.
 Now we have more compilers, and x86/64 isn't looking quite like the
 monopoly it used to be, so this interface will probably need to
 change. There's no conspiracy here, it's just "what worked" back in 
 the day,
 and either it's unused or unimportant such that no one has tried to
 update it thus far. Since this is in core, it's mostly Sean's 
 territory, but
 I'm sure he'd welcome ideas.


 I actually do use core.cpuid and find it very useful.


You are a stupid man. She is an old hag.
Oct 30 2011
prev sibling parent reply Don <nospam nospam.com> writes:
On 30.10.2011 02:49, Manu wrote:

 What's the deal with core.cpuid?
 I realise it is an x86 opcode, but is that something that you really
 want totally bare in core like that?
 I'm experimenting with other architectures, and some sort of
 core.processorInfo would be really nice, surely an API for this stuff
 should be more generalised...?


core.cpuid exists *because the runtime needs it*. It's deliberately 
_very_ low level. For example, it is essential that it does NOT perform 
any memory allocation. The information it provides is CPU-dependent.

Basically -- don't use core.cpuid unless you're programming in asm.

Indeed, there should be a higher level module (std.sysinfo ?) for more 
general use.
Oct 31 2011
next sibling parent reply Manu <turkeyman gmail.com> writes:
in std? what's the story with core? is it being deprecated?
I would think that cpuid should be a subset of a generalised sysinfo (or
processorinfo perhaps)... something you can optionally obtain if you first
identify that you're on an x86.

Why would there be a 'higher level' module? I'd like a low level query like
that for all processors. It just seems weird having an x86-only feature
exposed directly in core.

On 31 October 2011 09:11, Don <nospam nospam.com> wrote:


 On 30.10.2011 02:49, Manu wrote:


 What's the deal with core.cpuid?
 I realise it is an x86 opcode, but is that something that you really
 want totally bare in core like that?
 I'm experimenting with other architectures, and some sort of
 core.processorInfo would be really nice, surely an API for this stuff
 should be more generalised...?


 core.cpuid exists *because the runtime needs it*. It's deliberately _very_
 low level. For example, it is essential that it does NOT perform any memory
 allocation. The information it provides is CPU-dependent.

 Basically -- don't use core.cpuid unless you're programming in asm.

 Indeed, there should be a higher level module (std.sysinfo ?) for more
 general use.
Oct 31 2011
parent Don <nospam nospam.com> writes:
On 31.10.2011 09:34, Manu wrote:

 in std? what's the story with core? is it being deprecated?
 I would think that cpuid should be a subset of a generalised sysinfo (or
 processorinfo perhaps)... something you can optionally obtain if you
 first identify that you're on an x86.

 Why would there be a 'higher level' module? I'd like a low level query
 like that for all processors. It just seems weird having an x86-only
 feature exposed directly in core.


It isn't entirely x86 specific. There are some stubs for other 
processors (and there's a few things in there which are Itanium-specific).


 On 31 October 2011 09:11, Don <nospam nospam.com
 <mailto:nospam nospam.com>> wrote:

     On 30.10.2011 02:49, Manu wrote:

         What's the deal with core.cpuid?
         I realise it is an x86 opcode, but is that something that you really
         want totally bare in core like that?
         I'm experimenting with other architectures, and some sort of
         core.processorInfo would be really nice, surely an API for this
         stuff
         should be more generalised...?


     core.cpuid exists *because the runtime needs it*. It's deliberately
     _very_ low level. For example, it is essential that it does NOT
     perform any memory allocation. The information it provides is
     CPU-dependent.

     Basically -- don't use core.cpuid unless you're programming in asm.

     Indeed, there should be a higher level module (std.sysinfo ?) for
     more general use.
Oct 31 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
	charset=us-ascii

core contains the stuff that is intrinsic to the D language. It's separate f=
rom std for a number of reasons, but one practical reason is to help prevent=
 large portions of the standard library being pulled into all apps simply be=
cause something in the runtime code wanted to do formatted IO, for example. T=
hink of core like java.lang.=20

Sent from my iPhone

On Oct 31, 2011, at 1:34 AM, Manu <turkeyman gmail.com> wrote:


 in std? what's the story with core? is it being deprecated?
 I would think that cpuid should be a subset of a generalised sysinfo (or p=


rocessorinfo perhaps)... something you can optionally obtain if you first id=
entify that you're on an x86.

=20
 Why would there be a 'higher level' module? I'd like a low level query lik=


e that for all processors. It just seems weird having an x86-only feature ex=
posed directly in core.

=20
 On 31 October 2011 09:11, Don <nospam nospam.com> wrote:
 On 30.10.2011 02:49, Manu wrote:
 What's the deal with core.cpuid?
 I realise it is an x86 opcode, but is that something that you really
 want totally bare in core like that?
 I'm experimenting with other architectures, and some sort of
 core.processorInfo would be really nice, surely an API for this stuff
 should be more generalised...?
=20
 core.cpuid exists *because the runtime needs it*. It's deliberately _very_=


 low level. For example, it is essential that it does NOT perform any memory=
 allocation. The information it provides is CPU-dependent.

=20
 Basically -- don't use core.cpuid unless you're programming in asm.
=20
 Indeed, there should be a higher level module (std.sysinfo ?) for more gen=


eral use.

=20
=20
=20
=20
=20
=20
Oct 31 2011