[SOLVED] Linux local 2.2.16 #16 Fri Jun 9 18:25:17 PDT 2000 i?86 unknown

stf92 · 08-03-2014, 03:18 PM

Quote:

Originally Posted by Didier Spaier

So please tell us from where the NVIDIA installer can get the "machine is an i686" information in case of a Slackware 7.1 system.

Thousands of ways to do that. Most simple of all: the CPUID instruction, provided the installer knows it is running on the iAPX architecture. Most CPU manufacturers don't even provide something like the CPUID instruction. The software is supposed to inquire the CPU type by some other means, like writing and reading its registers.

Didier Spaier · 08-03-2014, 03:33 PM

Quote:

Originally Posted by stf92

Thousands of ways to do that. Most simple of all: the CPUID instruction, provided the installer knows it is running on the iAPX architecture. Most CPU manufacturers don't even provide something like the CPUID instruction. The software is supposed to inquire the CPU type by some other means, you really know what you are like writing and reading its registers.

Please attach to your next post or provide an URL to a program that you will write, that will just display the machine's architecture (e.g. i686 in the case of your box with Slackware 7.1), that could have been part of, or used by the NVIDIA installer (if only the guys that wrote it would have been as smart as you are).

Of course this program will run on a Slackware 7.1 including a Linux kernel version 2.2.16.

You can use any language you want, provided the program can be assembled/compiled and run on a stock Slackware 7.1 system. That can even be a shell script.

You don't have to use "thousands of ways": only one will suffice to convince us that you actually know what you are talking about. Till then, we'll stay in doubt.

Goobers · 08-03-2014, 04:48 PM

Quote:

Originally Posted by stf92

Thousands of ways to do that. Most simple of all: the CPUID instruction, provided the installer knows it is running on the iAPX architecture. Most CPU manufacturers don't even provide something like the CPUID instruction. The software is supposed to inquire the CPU type by some other means, like writing and reading its registers.

Err? no, EVERY CPU manufacturer actually does provide exactly that, a CPU-ID. But they provide it as specific sequence code.

The programs, uname and CPUID, etc... all have to "translate" that code into something more meaningful to the user.

You continue to bitch about uname being "dumb." Can you prove to us, that an un-updated version of CPUID (program) from around the same distro release, can do any better? Is there ANY such program released at that time, not updated since that can?

re: Didier Spaier

There's a slight flaw in that... unless they program a "version" check into uname, it shouldn't have any version dependencies. Its function and calls should be the same now as it was 10-15 years ago. The only real difference being its database/look up table. Uname, or any program similar to CPUID from 10 years should run on modern computers, only erroring out due to not knowing WHAT the modern computer name actually is. And in reverse, a current version of it should run in a 10 year old OS and recognize just about everything before that OS, and after that OS, up until the time the program was last updated.

The real issue is simply that the database/look up table didn't (couldn't!) have "future" entries, and stf92 is flat out refusing to accept that.

stf92 · 08-03-2014, 04:52 PM

@Didier Spaier:

See attached file. If the CPU predates the 586, then some extra work must be done by the program. First step:

Code:

PUSH   SP
POP    AX     ; get back the  value pushed?
CMP    AX,SP  ; if same, it is 80286 or higher
JNZ    IS_86  ; otherwise, it is 8088/8086

Second step: try to set the IOPL bits in the flags register; the 80386 and and 80486 have them, the 80286 will not allow them to be set; the 80386 and 80486 will.

Third step: determine whether the chip is an 80386. The key difference is the alignment check bit in the flags register; the 80486 has one, the 80386 does not.

The attached program can be assembled under any operating system, with only slight changes in the assembler directives. Also, the assembler should know the syntax. This is the Intel syntax.

Didier Spaier · 08-03-2014, 05:18 PM

I get only errors trying to assemble that, be it using as or as86.

Did you actually try it? If that is the case, please provide the command line you used.

stf92 · 08-03-2014, 05:53 PM

Code:

C:\5>ml -c getid.asm
Microsoft (R) Macro Assembler Version 6.11
Copyright (C) Microsoft Corp 1981-1993. All rights reserved.

 Assembling: getid.asm
C:\5>

I'm attaching the output: getid_obj.txt.

Didier Spaier · 08-03-2014, 06:02 PM

Are you kidding? I'd expect that working on Slackware, not on Windows!

Code:

~$ cd /tmp 
/tmp$ file getid_obj.txt 
getid_obj.txt: 8086 relocatable (Microsoft)
/tmp$ ./getid_obj.txt 
bash: ./getid_obj.txt: cannot execute binary file
/tmp$

stf92 · 08-03-2014, 06:07 PM

Erase the initial comment. Then you'll get something more legible. Now the assembler directives can give you some trouble. Mostly, the DB directive. With only slight modifications, I guess as86 will be able to assemble it.

Didier Spaier · 08-03-2014, 06:13 PM

Quote:

Originally Posted by stf92

Erase the initial comment. Then you'll get something more legible.

Erasing the initial comment was the first thing I did, to no avail.

Quote:

Now the assembler directives can give you some trouble. Mostly, the DB directive. With only slight modifications, I guess as86 will be able to assemble it.

No guess allowed. Please provide something that as86 can assemble without further modification, or stay silent.

stf92 · 08-03-2014, 06:19 PM

I'll do something better. Here you have the .exe which you can run in a DOS box.

Didier Spaier · 08-03-2014, 06:22 PM

Quote:

Originally Posted by stf92

I'll do something better. Here you have the .exe which you can run in a DOS box.

A DOS box? Is that a special kind of Slackware system? Are you laughing at me?

As already requested, please provide something that can be assembled/compiled on Slackware 7.1 or I won't take you seriously.

kikinovak · 08-04-2014, 01:30 AM

@stf92: why not try to compile FreeCAD on your abacus?

Goobers · 08-04-2014, 04:31 AM

Just for shits and giggles...

stf92 · 08-04-2014, 11:29 PM

@Didier Spaier:

You made me work a little, but it was fun. Assemble and link the attached file with

Code:

$ as -o getid_04.o getid_04.txt
$ ld -o getid_04 getid_04.o

Run with

Code:

$ ./getid_04

You can run it under Slackware 7.1 on any machine with Pentium I or better. It would be easy to make it run on older x86 machines by the addition of the appropriate source code, as suggested somewhere above.

Compilation under 7.1 however is problematic, as GAS supports Intel syntax only from 2.10 on. The entire source would have to be rewritten in AT&T syntax, making it thus compilable by any GAS version.

Didier Spaier · 08-05-2014, 02:23 PM

Good, that works on my Slackware 64-14.1, this is a progress:

Code:

/tmp$ ./getid_04 
Highest input value for CPUID = 0000000AH
Vendor identification =         GenuineIntel
Family =                        06H
Model =                         0FH
Stepping ID =                   0AH
Feature register =              BFEBFBFFH
/tmp$

Next exercise is to make it compile on Slackware 7.1 and decode the machine name as done by uname in recent Slackware versions.