[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Don clugd...@yahoo.com.au 2011-04-13 13:50:34 PDT --- https://github.com/D-Programming-Language/druntime/commit/5959d1e1cfecf0755db4cc14c2b595aa0a797bde -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 --- Comment #7 from Russel Winder rus...@russel.org.uk 2011-02-27 05:51:03 PST --- David has already reported the cannot cope with multiple CPUs bug as Issue 4462, dated 2010-07-14. So no movement on that after 7 months :-( I think this pair of bugs has to be treated as an urgent blocking bug and attacked immediately. Can cpuid.d be separated out so that we can work on it? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 --- Comment #8 from Don clugd...@yahoo.com.au 2011-02-27 06:46:37 PST --- (In reply to comment #7) David has already reported the cannot cope with multiple CPUs bug as Issue 4462, dated 2010-07-14. So no movement on that after 7 months :-( I think this pair of bugs has to be treated as an urgent blocking bug and attacked immediately. Can cpuid.d be separated out so that we can work on it? Yes. It has absolutely no dependencies on anything. Just copy it. You can compile it as a standalone file. BTW, there's a good chance the 64 bit code will work as-is, just by changing the version. The reason is that 'cpuid' acts as a 32-bit instruction even on 64 bits. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 --- Comment #4 from Russel Winder rus...@russel.org.uk 2011-02-20 02:51:59 PST --- I don't agree this is an enhancement, it is a bug, even if the 64-bit stuff is in early days. OpenMP, OpenMPI, just::thread and all the other C, C++ and Fortran paralellism frameworks handle this correctly. Why is this being handled by assembly code, all the operating systems must have APIs for handling this? Of course with Mac hardware with 64-bit processors where the boot ROM is 32-bit the OS boots 32-bit -- since Mac OS X refuses to boot 64-bit in this case. A hypothesis: the current assembly code can only deal with a single processor which is why it reports 4 in 32-bit mode on my dual quad-core workstation. If this is the case should a new bug be raised or can this be handled here? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 Brad Roberts bra...@puremagic.com changed: What|Removed |Added CC||bra...@puremagic.com Platform|Other |x86_64 OS/Version|Windows |All Severity|enhancement |major --- Comment #5 from Brad Roberts bra...@puremagic.com 2011-02-20 03:07:29 PST --- I agree, it's pretty important as parts of druntime and phobos use cpu info. Fixed up the platform as well. Don, is this something you might be able to own? You've done a lot of the past cpuid stuff, right? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 --- Comment #6 from Don clugd...@yahoo.com.au 2011-02-20 08:40:20 PST --- (In reply to comment #4) I don't agree this is an enhancement, it is a bug, It's neither. It is a task. Bugzilla's options are ridiculously limited. Why is this being handled by assembly code, all the operating systems must have APIs for handling this? The most recent ones do, the older ones don't. Really, this code is primarily intended for determining which features should be supported for low-level operations used by the runtime; and as such, it must be available at a very early stage in the initialization process, regardless of the OS. It replaces several ad-hoc and incorrect functions which had been used in the runtime. It would be good to supplement this with systems calls for the most recent OSes, but to do this without breaking older OSes. Although, probably all 64-bit OSes support it, so maybe it's only a issue for 32-bit systems. Of course with Mac hardware with 64-bit processors where the boot ROM is 32-bit the OS boots 32-bit -- since Mac OS X refuses to boot 64-bit in this case. A hypothesis: the current assembly code can only deal with a single processor which is why it reports 4 in 32-bit mode on my dual quad-core workstation. If this is the case should a new bug be raised or can this be handled here? That should be a new bug. The value should be correct, if the BIOS has done its job in setting the processor APIC values correctly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 David Simcha dsim...@yahoo.com changed: What|Removed |Added Summary|core.cpuid broken on 64 |core.cpuid not implemented ||on 64 Severity|normal |enhancement --- Comment #3 from David Simcha dsim...@yahoo.com 2011-02-19 12:08:36 PST --- Ok, you're right. The whole thing's versioned out. Editing the title and changing to enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
