6

I was reading over this question and wondered if the accepted answer might also be a way to determine the architecture. For instance, in asm could I push a WORD onto the stack and then check SP. Compare the new SP to the old SP:

Diff of 4 means 32 bit
Diff of 8 means 64 bit

Am I correct in this thinking?

Community
  • 1
  • 1
IAbstract
  • 19,551
  • 15
  • 98
  • 146
  • 2
    I was under the impression that 32-bit and 64-bit assembly instructions were different. At least in x86 vs. x86-64. – Powerlord Apr 02 '10 at 20:32
  • 3
    I do not know, but if you simply want to detect 64-bit support you can use the CPUID instruction. – Andreas Rejbrand Apr 02 '10 at 20:32
  • 2
    Normally it is known at compile time whether the target is 64 bit or 32 bit. It would be a rare case indeed that this trick would be useful. Also, my guess is there's a way to examine the relevant flag directly without having to do some sort of trick like this. – Dietrich Epp Apr 02 '10 at 20:38
  • @OMG: For push and pop, the opcodes are decoded the same. 0xFF for instance is push in x86 for any mode. The processor determines the correct stack size based on your execution mode. – Jeff B Apr 02 '10 at 20:52
  • You need to specify what CPU/architecture you're talking about - I'm guessing you are only interested in x86/x86-64 but you failed to tag appropriately, so who knows ? – Paul R Apr 02 '10 at 21:30
  • 1
    For machine code that detects what mode it's running in, see this function that returns 16, 32, or 64: [Determine your language's version](https://codegolf.stackexchange.com/a/139717). Or for just 32 vs. 64, see [x86-32 / x86-64 polyglot machine-code fragment that detects 64bit mode at run-time?](https://stackoverflow.com/q/38063529) – Peter Cordes Jun 21 '18 at 23:08

2 Answers2

6

No, because the size of your stack is based on what mode you are running in (real, protected, long/64, vm86, smm, etc), not on the architecture. If your assembly is running in protected mode for instance, your stack will be 32 bits (or 16 if your operands are 16 bits), even if your processor is x86-64.

Like someone in the comments mentioned, CPUID is the only reliable way to tell what your architecture is.

Jeff B
  • 29,943
  • 7
  • 61
  • 90
0

For machine code that detects what mode it's running in, see this code-golf x86 machine-code function that returns 16, 32, or 64: Determine your language's version. The same machine-code bytes give different results depending on what mode they're decoded in.

Or for just 32 vs. 64, see x86-32 / x86-64 polyglot machine-code fragment that detects 64bit mode at run-time?

In most cases, you won't need to detect the current mode, because you know what your code was compiled/assembled for. (e.g. in NASM, %ifidn __BITS__ 32, or check %ifidn __OUTPUT_FORMAT__, elf32 which works in YASM as well.)

To detect CPU capability regardless of current mode, use CPUID. How do you detect the CPU architecture type during run-time with GCC and inline asm? (or use cpuid.h: How do I call "cpuid" in Linux?)

This still doesn't tell you whether the OS you're running under will support 64-bit executables; if you want to know that you should just check that you're running under a 64-bit OS. CPUID can't help you with that: the mechanisms for 32-bit programs to query the OS are of course OS-specific.

IMO "the architecture" of your CPU is not the right question to be asking, in almost all cases. (i.e. unless you're writing your own kernel, or writing a CPU-info program). Knowing it doesn't help your program decide what to do.

32-bit-only x86 CPUs haven't been made for years, and are getting more and more rare. But 32-bit OSes are still in use on 64-bit-capable CPUs.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847