On Friday 16 January 2004 04:16, Alexandre Julliard wrote:
> Robert Lunnon <[EMAIL PROTECTED]> writes:
> > This is true, but it is not very time consuming. I had considered
> > caching the cpuid results which would eliminate the multiple handling but
> > didn't feel it was worth the effort. This f
Robert Lunnon <[EMAIL PROTECTED]> writes:
> This is true, but it is not very time consuming. I had considered caching the
> cpuid results which would eliminate the multiple handling but didn't feel it
> was worth the effort. This function does not tend to get called often in
> windows programs
On Thursday 15 January 2004 15:53, Alexandre Julliard wrote:
> Robert Lunnon <[EMAIL PROTECTED]> writes:
> > 1. The original cpuid and i386 detect are merged into a single assembly
> > call for convenience.
>
> Much less readable IMO.
A little less readable in my opinion, this assembly code is doc
Robert Lunnon <[EMAIL PROTECTED]> writes:
> 1. The original cpuid and i386 detect are merged into a single assembly call
> for convenience.
Much less readable IMO.
> 2. The data is then interpreted into a structure for use. Understanding CPUID
> means knowing the cpuid_t structure and CPUID_Is
On Thursday 15 January 2004 10:45, Alexandre Julliard wrote:
> Robert Lunnon <[EMAIL PROTECTED]> writes:
> > Improves CPUID instruction support in cpu.c by reorganising the existing
> > FREEBSD code. Added more robust cpuid detection with built in 386
> > detection. Code should work for all i386 pl
Robert Lunnon <[EMAIL PROTECTED]> writes:
> Improves CPUID instruction support in cpu.c by reorganising the existing
> FREEBSD code. Added more robust cpuid detection with built in 386 detection.
> Code should work for all i386 platforms and has been tested under solaris.
> Created subroutines
