[PATCH] Various improvement in TOOLS/cpuinfo.c
Hi, The attached patch 1. fixes inline asm problems to make it produce right answer with icc; hopefully the cpuid/ebx/PIC staff won't matter since it's not used in a library; 2. renames some flags to resemble the behavior of /proc/cpuinfo, most noticeably sse3->pni; 3. adds cyrix_arr support so the mtrr function in vidix might work; I don't have a M1 or M2 for testing, though. 4. enables cpuinfo to print correct names for Pentium III. 5. makes cpuinfo recognize extended families and models. Some testing for 3 is welcome. Cyrix M1 or M2 should have cyrix_arr but no mtrr, and 5x86, MediaGX or GXm should have neither. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
2006/4/25, Zuxy Meng <zuxy.meng@gmail.com>:
Hi,
Absolutely sorry, bug found in previous patch. This one fixes it. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
On Tue, Apr 25, 2006 at 04:22:15PM +0800, Zuxy Meng wrote:
2006/4/25, Zuxy Meng <zuxy.meng@gmail.com>:
Absolutely sorry, bug found in previous patch. This one fixes it.
Please resend an updated version of your patch, stacking patches is more work and error-prone.
--- main/TOOLS/cpuinfo.c 2006-04-25 16:19:42.000000000 +0800 +++ main.new/TOOLS/cpuinfo.c 2006-04-25 16:17:23.000000000 +0800 @@ -228,7 +228,7 @@ family += (regs.eax >> 20) & 0xff; model += ((regs.eax >> 16) & 0xf) << 4; } - +
Rejected: cosmetics Please resend an updated patch without the cosmetics. Diego
2006/4/25, Diego Biurrun <diego@biurrun.de>:
Please resend an updated version of your patch, stacking patches is more work and error-prone.
Rejected: cosmetics
Please resend an updated patch without the cosmetics.
OK, here we go. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
On Tuesday, 25 April 2006 at 10:44, Zuxy Meng wrote: [...]
@@ -147,16 +158,16 @@ { 15, "cmov", "Conditional Move/Compare Instruction" }, { 16, "pat", "Page Attribute Table" }, { 17, "pse36", "Page Size Extension 36-bit" }, - { 18, "psn", "Processor Serial Number" }, + { 18, "pn", "Processor Serial Number" }, ^^^ Nit: misalignment. ;)
{ 19, "cflsh", "CFLUSH instruction" }, - { 21, "ds", "Debug Store" }, + { 21, "dts", "Debug Store" },
Same here.
{ 22, "acpi", "Thermal Monitor and Clock Ctrl" }, { 23, "mmx", "MMX Technology" }, { 24, "fxsr", "FXSAVE/FXRSTOR" }, { 25, "sse", "SSE Extensions" }, { 26, "sse2", "SSE2 Extensions" }, { 27, "ss", "Self Snoop" }, - { 28, "htt", "Multi-threading" }, + { 28, "ht", "Multi-threading" },
And here. Don't be afraid to add/remove a single space if the change warrants it. :) Regards, R. -- MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/ There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
Hi, 2006/4/25, Dominik 'Rathann' Mierzejewski <dominik@rangers.eu.org>:
On Tuesday, 25 April 2006 at 10:44, Zuxy Meng wrote: [...]
@@ -147,16 +158,16 @@ { 15, "cmov", "Conditional Move/Compare Instruction" }, { 16, "pat", "Page Attribute Table" }, { 17, "pse36", "Page Size Extension 36-bit" }, - { 18, "psn", "Processor Serial Number" }, + { 18, "pn", "Processor Serial Number" }, ^^^ Nit: misalignment. ;)
{ 19, "cflsh", "CFLUSH instruction" }, - { 21, "ds", "Debug Store" }, + { 21, "dts", "Debug Store" },
Same here.
{ 22, "acpi", "Thermal Monitor and Clock Ctrl" }, { 23, "mmx", "MMX Technology" }, { 24, "fxsr", "FXSAVE/FXRSTOR" }, { 25, "sse", "SSE Extensions" }, { 26, "sse2", "SSE2 Extensions" }, { 27, "ss", "Self Snoop" }, - { 28, "htt", "Multi-threading" }, + { 28, "ht", "Multi-threading" },
And here. Don't be afraid to add/remove a single space if the change warrants it. :)
Thanks:-) But, er, will it better to remove those stuff all together? MPlayer doesn't need a human readable description actually. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
2006/4/25, Zuxy Meng <zuxy.meng@gmail.com>:
Hi,
2006/4/25, Dominik 'Rathann' Mierzejewski <dominik@rangers.eu.org>:
On Tuesday, 25 April 2006 at 10:44, Zuxy Meng wrote: [...]
@@ -147,16 +158,16 @@ { 15, "cmov", "Conditional Move/Compare Instruction" }, { 16, "pat", "Page Attribute Table" }, { 17, "pse36", "Page Size Extension 36-bit" }, - { 18, "psn", "Processor Serial Number" }, + { 18, "pn", "Processor Serial Number" }, ^^^ Nit: misalignment. ;)
{ 19, "cflsh", "CFLUSH instruction" }, - { 21, "ds", "Debug Store" }, + { 21, "dts", "Debug Store" },
Same here.
{ 22, "acpi", "Thermal Monitor and Clock Ctrl" }, { 23, "mmx", "MMX Technology" }, { 24, "fxsr", "FXSAVE/FXRSTOR" }, { 25, "sse", "SSE Extensions" }, { 26, "sse2", "SSE2 Extensions" }, { 27, "ss", "Self Snoop" }, - { 28, "htt", "Multi-threading" }, + { 28, "ht", "Multi-threading" },
And here. Don't be afraid to add/remove a single space if the change warrants it. :)
Thanks:-) But, er, will it better to remove those stuff all together? MPlayer doesn't need a human readable description actually.
Better leave it. We are humans. I could not get from top of my head what "pn" is.
2006/4/25, Ivan Kalvachev <ikalvachev@gmail.com>:
2006/4/25, Zuxy Meng <zuxy.meng@gmail.com>:
Hi,
Thanks:-) But, er, will it better to remove those stuff all together? MPlayer doesn't need a human readable description actually.
Better leave it. We are humans. I could not get from top of my head what "pn" is.
OK. The (hopefully) final patch. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Zuxy Meng wrote:
2006/4/25, Ivan Kalvachev <ikalvachev@gmail.com>:
2006/4/25, Zuxy Meng <zuxy.meng@gmail.com>:
Hi,
Thanks:-) But, er, will it better to remove those stuff all together? MPlayer doesn't need a human readable description actually. Better leave it. We are humans. I could not get from top of my head what "pn" is.
OK. The (hopefully) final patch.
- { 28, "htt", "Multi-threading" }, + { 28, "ht", "Multi-threading" },
Isn't this "Hyper-threading"? ...or is that just a marketing name? -Corey
2006/4/26, Corey Hickey <bugfood-ml@fatooh.org>:
Zuxy Meng wrote:
- { 28, "htt", "Multi-threading" }, + { 28, "ht", "Multi-threading" },
Isn't this "Hyper-threading"? ...or is that just a marketing name?
Yes it's the original hyper-threading bit, but dual core cpu sets it, too, so Intel has renamed it "multi-threading". However, for historical reasons the flag remains "ht". -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
2006/4/26, Zuxy Meng <zuxy.meng@gmail.com>:
2006/4/26, Corey Hickey <bugfood-ml@fatooh.org>:
Zuxy Meng wrote:
- { 28, "htt", "Multi-threading" }, + { 28, "ht", "Multi-threading" },
Isn't this "Hyper-threading"? ...or is that just a marketing name?
Yes it's the original hyper-threading bit, but dual core cpu sets it, too, so Intel has renamed it "multi-threading". However, for historical reasons the flag remains "ht".
How about "Hyper/Multi-threading"?
2006/4/27, Ivan Kalvachev <ikalvachev@gmail.com>:
2006/4/26, Zuxy Meng <zuxy.meng@gmail.com>:
Yes it's the original hyper-threading bit, but dual core cpu sets it, too, so Intel has renamed it "multi-threading". However, for historical reasons the flag remains "ht".
How about "Hyper/Multi-threading"?
Dosen't matter. The program never uses this field anyway. Better to change them to comments. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
2006/4/25, Zuxy Meng <zuxy.meng@gmail.com>:
OK. The (hopefully) final patch.
No further comments? -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi, On Tue, May 09, 2006 at 11:34:10AM +0200, Guillaume Poirier wrote:
Zuxy Meng wrote:
2006/4/25, Zuxy Meng <zuxy.meng@gmail.com>:
OK. The (hopefully) final patch.
No further comments?
I guess I can commit it soon unless someone shouts.
"=b" (regs.ebx) I think this was not done on purpose since it would break compilation with -fPIC (not sure why it mattered though) Greetings, Reimar Döffinger
Hi, 2006/5/9, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>:
Hi,
"=b" (regs.ebx)
I think this was not done on purpose since it would break compilation with -fPIC (not sure why it mattered though)
Does this matter, since cpuinfo is a standalone executable? -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi, On 5/10/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
Hi,
2006/5/9, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>:
Hi,
"=b" (regs.ebx)
I think this was not done on purpose since it would break compilation with -fPIC (not sure why it mattered though)
Does this matter, since cpuinfo is a standalone executable?
Thanks a lot Zuxy. Patch applied. this patch also fixes compilation on AMD-64, so that's more than enough reasons to appliy right now. Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
On May 14, 2006, at 4:26 PM, Guillaume POIRIER wrote:
Hi,
On 5/10/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
Hi,
2006/5/9, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>:
Hi,
"=b" (regs.ebx)
I think this was not done on purpose since it would break compilation with -fPIC (not sure why it mattered though)
Does this matter, since cpuinfo is a standalone executable?
Thanks a lot Zuxy. Patch applied. this patch also fixes compilation on AMD-64, so that's more than enough reasons to appliy right now.
Hello friends I've been checking in on and off to see if any progress was made on the Intel Mac front. I'm seeing this during configure: TOOLS/cpuinfo.c: In function ‘cpuid’: TOOLS/cpuinfo.c:46: error: can't find a register in class ‘BREG’ while reloading ‘asm’ Compiling on the command-line (gcc -o TOOLS/cpuinfo TOOLS/cpuinfo.c) gives the same error so it's not something configure is doing. -- ===================================================================== Mohammad A. Haque http://www.haque.net/ mhaque@haque.net "Alcohol and calculus don't mix. Don't drink and derive." --Unknown =====================================================================
Hi, 2006/5/15, Mohammad A. Haque <mhaque@haque.net>:
Hello friends
I've been checking in on and off to see if any progress was made on the Intel Mac front. I'm seeing this during configure:
TOOLS/cpuinfo.c: In function 'cpuid': TOOLS/cpuinfo.c:46: error: can't find a register in class 'BREG' while reloading 'asm'
Compiling on the command-line (gcc -o TOOLS/cpuinfo TOOLS/cpuinfo.c) gives the same error so it's not something configure is doing.
Funny. What gcc version are you using? Seems that Apple has made some modifications to vanilla gcc because "=b" is used even in Linux kernel. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
On May 15, 2006, at 8:35 AM, Zuxy Meng wrote:
Hi,
2006/5/15, Mohammad A. Haque <mhaque@haque.net>:
Hello friends
I've been checking in on and off to see if any progress was made on the Intel Mac front. I'm seeing this during configure:
TOOLS/cpuinfo.c: In function 'cpuid': TOOLS/cpuinfo.c:46: error: can't find a register in class 'BREG' while reloading 'asm'
Compiling on the command-line (gcc -o TOOLS/cpuinfo TOOLS/cpuinfo.c) gives the same error so it's not something configure is doing.
Funny. What gcc version are you using? Seems that Apple has made some modifications to vanilla gcc because "=b" is used even in Linux kernel.
[mhaque@batmobile main]$ gcc --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250) -- ===================================================================== Mohammad A. Haque http://www.haque.net/ mhaque@haque.net "Alcohol and calculus don't mix. Don't drink and derive." --Unknown =====================================================================
2006/5/15, Mohammad A. Haque <mhaque@haque.net>:
[mhaque@batmobile main]$ gcc --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250)
Hmm, how about this patch? -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
On May 15, 2006, at 9:30 AM, Zuxy Meng wrote:
2006/5/15, Mohammad A. Haque <mhaque@haque.net>:
[mhaque@batmobile main]$ gcc --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250)
Hmm, how about this patch?
Compiles fine now. [mhaque@batmobile mplayerosx]$ gcc -o main/TOOLS/cpuinfo main/TOOLS/ cpuinfo.c [mhaque@batmobile mplayerosx]$ main/TOOLS/cpuinfo vendor_id : GenuineIntel cpu family : 6 model : 14 stepping : 8 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat cflsh dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor vmx est tm2 xtpr nx cpu MHz : 1072.808 model name : Genuine Intel(R) CPU T2600 @ 2.16GHz Thanks -- ===================================================================== Mohammad A. Haque http://www.haque.net/ mhaque@haque.net "Alcohol and calculus don't mix. Don't drink and derive." --Unknown =====================================================================
Hi, On 5/15/06, Mohammad A. Haque <mhaque@haque.net> wrote:
On May 15, 2006, at 9:30 AM, Zuxy Meng wrote:
2006/5/15, Mohammad A. Haque <mhaque@haque.net>:
[mhaque@batmobile main]$ gcc --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250)
Hmm, how about this patch?
Compiles fine now.
Applied, thanks. Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
2006/5/15, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
Applied, thanks.
Well, the patch may break compilation on x86_64 since it only saves ebx, not rbx. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi, On 5/15/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
2006/5/15, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
Applied, thanks.
Well, the patch may break compilation on x86_64 since it only saves ebx, not rbx.
Ok, good to know. The previous version (before last night) wasn't working on amd64 anyhow, so at least your patch fixes a known regression. I'm sure there's a way to support "macintel", amd64 and ia34... Also, do you know if the "b" asm contrain is supposed to work with gcc 2.95? Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
Hi, 2006/5/16, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
Ok, good to know. The previous version (before last night) wasn't working on amd64 anyhow, so at least your patch fixes a known regression.
I'm sure there's a way to support "macintel", amd64 and ia34...
Will gcc define a macro like TARGET_64BIT under amd64?
Also, do you know if the "b" asm contrain is supposed to work with gcc 2.95?
It should be. I checked linux kernel 2.4.9, which builds on gcc 2.95, and it contains the '=b' constraint. So I guess it's a problem specific to darwin gcc. Apple modifies gcc/config/i386/i386.h a lot. BTW: Is gcc 2.95 the earliest version we provide support? -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi, On 5/15/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
Hi,
2006/5/16, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
Ok, good to know. The previous version (before last night) wasn't working on amd64 anyhow, so at least your patch fixes a known regression.
I'm sure there's a way to support "macintel", amd64 and ia34...
Will gcc define a macro like TARGET_64BIT under amd64?
Maybe it does, I have not been able to find much information about it besides http://gcc.gnu.org/onlinedocs/gccint/Defining-Mode-Macros.html and http://gcc.gnu.org/onlinedocs/gccint/Examples.html The simplest way is probably to test on an amd64 machine. In any case, no need to worry, the patch you sent today works on AMD64 (I just checked now as I'm home).
Also, do you know if the "b" asm contrain is supposed to work with gcc 2.95?
It should be. I checked linux kernel 2.4.9, which builds on gcc 2.95, and it contains the '=b' constraint. So I guess it's a problem specific to darwin gcc. Apple modifies gcc/config/i386/i386.h a lot.
BTW: Is gcc 2.95 the earliest version we provide support?
Yes. Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
2006/5/16, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
On 5/15/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
Hi,
2006/5/16, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
Ok, good to know. The previous version (before last night) wasn't working on amd64 anyhow, so at least your patch fixes a known regression.
I'm sure there's a way to support "macintel", amd64 and ia34...
Will gcc define a macro like TARGET_64BIT under amd64?
Maybe it does, I have not been able to find much information about it besides http://gcc.gnu.org/onlinedocs/gccint/Defining-Mode-Macros.html and http://gcc.gnu.org/onlinedocs/gccint/Examples.html
The simplest way is probably to test on an amd64 machine.
Would please try __x86_64__? See if it's defined under amd64, and undefined under x86 and amd64 with -m32.
In any case, no need to worry, the patch you sent today works on AMD64 (I just checked now as I'm home).
It might work, if the context use rbx as a 32 bit int; it mighty fail, if the context use rbx as a 64 bit pointer. There's no guarantee here:-( -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
2006/5/16, Zuxy Meng <zuxy.meng@gmail.com>:
2006/5/16, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
On 5/15/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
Hi,
2006/5/16, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
Ok, good to know. The previous version (before last night) wasn't working on amd64 anyhow, so at least your patch fixes a known regression.
I'm sure there's a way to support "macintel", amd64 and ia34...
Will gcc define a macro like TARGET_64BIT under amd64?
Maybe it does, I have not been able to find much information about it besides http://gcc.gnu.org/onlinedocs/gccint/Defining-Mode-Macros.html and http://gcc.gnu.org/onlinedocs/gccint/Examples.html
The simplest way is probably to test on an amd64 machine.
Would please try __x86_64__? See if it's defined under amd64, and undefined under x86 and amd64 with -m32.
In any case, no need to worry, the patch you sent today works on AMD64 (I just checked now as I'm home).
It might work, if the context use rbx as a 32 bit int; it mighty fail, if the context use rbx as a 64 bit pointer. There's no guarantee here:-(
I checked gcc's source and confirmed that __x86_64__ would indicate that we're under x86_64, so the attached patch should be OK. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi On Thu, May 18, 2006 at 02:38:25AM +0800, Zuxy Meng wrote:
2006/5/16, Zuxy Meng <zuxy.meng@gmail.com>:
2006/5/16, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
On 5/15/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
Hi,
2006/5/16, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
Ok, good to know. The previous version (before last night) wasn't working on amd64 anyhow, so at least your patch fixes a known regression.
I'm sure there's a way to support "macintel", amd64 and ia34...
Will gcc define a macro like TARGET_64BIT under amd64?
Maybe it does, I have not been able to find much information about it besides http://gcc.gnu.org/onlinedocs/gccint/Defining-Mode-Macros.html and http://gcc.gnu.org/onlinedocs/gccint/Examples.html
The simplest way is probably to test on an amd64 machine.
Would please try __x86_64__? See if it's defined under amd64, and undefined under x86 and amd64 with -m32.
In any case, no need to worry, the patch you sent today works on AMD64 (I just checked now as I'm home).
It might work, if the context use rbx as a 32 bit int; it mighty fail, if the context use rbx as a 64 bit pointer. There's no guarantee here:-(
I checked gcc's source and confirmed that __x86_64__ would indicate that we're under x86_64, so the attached patch should be OK. [...] +#ifdef __x86_64__ + asm("mov %%rbx, %%rsi\n\t" +#else asm("mov %%ebx, %%esi\n\t" +#endif
any special reason why you dont use REG_S / REG_b defines here? [...] -- Michael In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Hi, On 5/17/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
2006/5/16, Zuxy Meng <zuxy.meng@gmail.com>:
It might work, if the context use rbx as a 32 bit int; it mighty fail, if the context use rbx as a 64 bit pointer. There's no guarantee here:-(
I checked gcc's source and confirmed that __x86_64__ would indicate that we're under x86_64, so the attached patch should be OK.
It is. Patch applied. Sorry for the delay and lack of testing if __x86_64__ was defined or not... Guillaume -- An Israeli man's life was saved when he was given a Palestinian man's heart in a heart transplant operation. The guy is doing fine, but the bad news is, he can't stop throwing rocks at himself. -- Jay Leno
2006/5/15, Mohammad A. Haque <mhaque@haque.net>:
On May 15, 2006, at 9:30 AM, Zuxy Meng wrote:
Compiles fine now.
[mhaque@batmobile mplayerosx]$ gcc -o main/TOOLS/cpuinfo main/TOOLS/ cpuinfo.c [mhaque@batmobile mplayerosx]$ main/TOOLS/cpuinfo vendor_id : GenuineIntel cpu family : 6 model : 14 stepping : 8 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat cflsh dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor vmx est tm2 xtpr nx cpu MHz : 1072.808 model name : Genuine Intel(R) CPU T2600 @ 2.16GHz
Well, things have become complex then. Obviously darwin gcc doesn't recognize 'b' in asm constraints and we have to save ebx to esi by hand. Then we have to distinguish x86 and x86_64 in cpuinfo.c. Is there an available macro? -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
On May 15, 2006, at 11:20 AM, Zuxy Meng wrote:
Well, things have become complex then. Obviously darwin gcc doesn't recognize 'b' in asm constraints and we have to save ebx to esi by hand. Then we have to distinguish x86 and x86_64 in cpuinfo.c. Is there an available macro?
Will this help you find the info you need? <http://developer.apple.com/documentation/DeveloperTools/Reference/ Assembler/index.html?http://developer.apple.com/documentation/ DeveloperTools/Reference/Assembler/ASMLayout/chapter_4_section_4.html> -- ===================================================================== Mohammad A. Haque http://www.haque.net/ mhaque@haque.net "Alcohol and calculus don't mix. Don't drink and derive." --Unknown =====================================================================
Hi, On 5/15/06, Mohammad A. Haque <mhaque@haque.net> wrote:
On May 14, 2006, at 4:26 PM, Guillaume POIRIER wrote:
Hi,
On 5/10/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
Hello friends
I've been checking in on and off to see if any progress was made on the Intel Mac front. I'm seeing this during configure:
TOOLS/cpuinfo.c: In function 'cpuid': TOOLS/cpuinfo.c:46: error: can't find a register in class 'BREG' while reloading 'asm'
Compiling on the command-line (gcc -o TOOLS/cpuinfo TOOLS/cpuinfo.c) gives the same error so it's not something configure is doing.
Was it working before I applied that patch? I don't understand why it would break on macintel... Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
On May 15, 2006, at 8:41 AM, Guillaume POIRIER wrote:
On 5/15/06, Mohammad A. Haque <mhaque@haque.net> wrote:
Hello friends
I've been checking in on and off to see if any progress was made on the Intel Mac front. I'm seeing this during configure:
TOOLS/cpuinfo.c: In function 'cpuid': TOOLS/cpuinfo.c:46: error: can't find a register in class 'BREG' while reloading 'asm'
Compiling on the command-line (gcc -o TOOLS/cpuinfo TOOLS/cpuinfo.c) gives the same error so it's not something configure is doing.
Was it working before I applied that patch? I don't understand why it would break on macintel...
Yep, was compiling without issues. -- ===================================================================== Mohammad A. Haque http://www.haque.net/ mhaque@haque.net "Alcohol and calculus don't mix. Don't drink and derive." --Unknown =====================================================================
participants (10)
-
Corey Hickey -
Diego Biurrun -
Dominik 'Rathann' Mierzejewski -
Guillaume Poirier -
Guillaume POIRIER -
Ivan Kalvachev -
Michael Niedermayer -
Mohammad A. Haque -
Reimar Döffinger -
Zuxy Meng