So I know that having a 32-bit PCI BAR (Base Address Register) can be accessed on a 64-bit Operating System (this link gives some information about it and I myself have tested it) (let us say it is a Linux OS) but can a 64-bit PCI BAR (Base Address Register) work with a 32-Bit Operating System?
Would be great if anyone can point to any documentation or an experience of their practical experiment regarding it.
Please feel free to ask for any clarifications regarding the query.
We did a test to confirm that if a 64-bit PCI BAR would work on a 32-bit system.
We created a 32-bit Virtual Machine on a 64-bit system having a 64-bit PCI BAR device attached and did pass through of the PCI function (virtual function, which is also 64-bit) onto the VM. When using the lspci command on the VM, we saw 64-bit BAR mapping of the passed through device on the 32-bit VM. We also sent packets (testing if the pass through is working on the VM), which worked as they normally should.
Following is the result of the lspci command on the 32-bit VM:
lspci Output
Related
Will there be a difference in the performance of a 32 bit operating system running on 64 bit processor and a 32 bit operating system running on 32 bit processor?
Just realized this didn't specify x86. I don't know if any ARMv8 CPUs are slower in ARMv7 mode than a similar-cost ARMv7 CPU.
You can't really compare apples-to-apples, because there's no such thing as a 64-bit CPU that's exactly the same as a 32-bit CPU except for supporting 64-bit mode. There are always other microarchitectural changes, too. (Like from Pentium M to Core2 on Intel.)
If we're talking about x86, then no. A 64-bit capable x86 CPU is no worse at running 32-bit code. This is called "legacy mode", as opposed to "compat mode" (32-bit user-space under 64-bit OS), but they perform the same.
In fact, the only CPUs that can't run in x86-64 mode these days are old, slow, or both. e.g. using a 32-bit-only CPU means you're running on Pentium4, Pentium-M, or an old Atom! Or Athlon-XP. Or an embedded x86 like Geode.
This is the same reason that 32-bit software is still widely used under Windows (although usually under a 64-bit OS).
The option you didn't mention is the high-performance one: 64-bit OS on a 64-bit CPU, even if you want to run 32-bit user-space code.
Especially if you have more than 1 or 2GB of RAM, it's likely that your system will run faster with a 64-bit kernel. 32-bit kernels can use more RAM, but it's ugly and not as fast as if the kernel can have all physical memory mapped into kernel-space virtual memory. See Linus Torvald's comments on PAE (Physical-Address Extensions)
See the x86 tag wiki for more about how x86 CPUs perform, and how to optimize for them.
Yes because you wouldn't make full use of all those 64bits. If you have a 32bits OS than you will only use that and not 64. However, if you were to have 64bits OS than it will make full use of those bits.
Also, please have a look at:
https://www.howtogeek.com/194119/why-are-most-programs-still-32-bit-on-a-64-bit-version-of-windows/
and
http://www.osnews.com/story/5768
Can 32bit UEFI BIOS work with 64bit OS or vice versa? I don't think it can, or at least it shouldn't. But it seems to be possible according to this thread.
For a CPU capable of both 32bit and 64bit, it's just a matter of operating mode I think. And I believe it's switchable. So is there any technical reason that makes it impossible or inappropriate for mixed OS/BIOS arch?
So, the short answer is: it depends on your architecture.
On x86 it is possible, if a little bit fiddly. A whole class of 64-bit devices shipping with 32-bit UEFI are supported out of the box by at least Debian's amd64 port (more info).
On ARM it is not, or rather 32-bit OS on 64-bit UEFI is technically possible (only would still require the operating system loader to be 64-bit), but even fiddlier than on x86. Launching a 64-bit operating system from 32-bit firmware is simply not supported by the architecture.
In school we've been taught that compilers compile a computer program to machine language. We've also been taught that the machine language consists of direct instructions to the hardware. Then how can the same compiled program run on several computer configurations with different hardware?
Depends what you mean by 'different hardware' if it is the same processor (or same family eg Intel x86) then the machine code instructions are the same.
If the extra hardware is different peripherals (screens, disks printers etc) then the operating system hides those details by giving you a consistent set of instructions to drive them
If you mean, how can you run a program for an ARM cpu on an Intel x86, then you can't - except by some sort of virtual machine emulator that reads each of the ARM instructions and either translates them into x86 or runs the same functionality as a set of x86 funcs and then returns the same answer that the ARM ones would have done.
Edit: I assume you mean PCs with different hw - ie different peripherals but the same processor family?
Talking to hardware doesn't involve specific instructions as such - it's mostly a matter of moving memory to specific locations where the operating system and/or device driver have specifically reserved for data going to that device. In the old days of DOS and BIOS you would then trigger an interupt to call a specific bit of code in the BIOS to act on that data and send it to the HW.
With an emulator or a virtual machine, either of which effectively translates the machine language on the fly.
I think it is more accurate to say that native compilers compile to a specific instruction set of a processor. Since there are families of processors that keep backwards compatibility: 8086 - 80386 - 80486 - 80586 - Dual Core - Quad Core...; then each processor runs the instructions of its ancestors. If you want to port your code across processor architectures, then you need for sure a virtual machine or emulator, like it was mentioned previously.
For some CPU-bound code using 64-bit variables, it is beneficial to use the Amd64 instruction set rather than x86. How can it be done under 32-bit Windows (e.g. Windows XP SP3)? Of course I assume a modern, Amd64-enabled CPU. I'm excluding the working but heavyweight method: running a full-blown 64-bit OS as a virtual machine, e.g. Ubuntu for Amd64 under Virtualbox.
I understand some assembly is needed, and there will restrictions, in particular addressing more memory than 32-bit Windows manages. But I'm thinking of purely computational tasks needing only a moderate amount of memory and no call to external functions.
There is no way to use Amd64 instructions (Long mode) in 32-bit general-purpose OS (without kernel modification/special drivers/hypervisor).
This is because:
1) to use native 64-bit instructions you need to switch into long mode. This is privileged action. 32-bit OS kernel can't continue to work if the CPU is switched into 64-bit mode, so you should switch back before entering a kernel
2) But kernel are often called asynchronously, for timer (scheduler) and other hardware interrupts (drivers). It will not save 64-bit registers nor change mode from long into protected.
May be it is possible to write special driver, which will do the 64-bit tasks on 32-bit OS, but such driver is more like 64-bit kernel and dynamic patcher of kernel. I know no one such solution.
You can only use MMX, SSE, SSE2, SSE3, AVX for accessing 64-bit ALU and registers of your CPU when running in 32-bit OS.
I can say, that Linux, some BSD, Mac OS X have a mode, when 64-bit kernel is used, but user-space software is 32-bit. In such case it will be possible to run both 32-bit and 64-bit applications, because kernel knows about 64-bit mode and can access 64-bit registers to do a task switch. As far as I know, MS Windows have not such mode itself (the W7 emulates 32bit mode, but this is called my MS as simulator so I assume it is not an in-kernel feature).
Other possibility (this is better, is your CPU has support of hardware virtualization), is to use 64-bit hypervisor (VMware/Xen, other overpriced solutions) with 32-bit and 64-bit guest OSes. VirtualBox is other option of using hypervisor, and it is free to use.
In general, running 64-bit code in a 32-bit OS kernel is going to be next to impossible, for the following reasons:
The 32-bit OS is unaware of the additional 64-bit registers (and upper 32-bits of the existing registers) and will not save them across task switches
The 32-bit OS is not prepared to enable 64-bit code execution. Enabling 64-bit code execution means switching to IA-32e paging (which requires an entirely different page table format) and setting CS.L = 1 and CS.D = 0 in the code segment descriptor in the GDT (or LDT). (See the IA-32 manuals, vol 3a/3b 5.2.1)
In principle, you may be able to workaround both problems by writing a new HAL for Windows, which operates in IA-32e mode, and switches to a 64-bit trampoline code segment to save and restore 64-bit registers. This is a rather complex task; take a look at the Windows DDK for details. You could also use an emulation approach, as VirtualBox and friends do, if your CPU supports VMX. But it would be much simpler to simply use a 64-bit OS from the start.
Firstly, what is this called? Is this the system's "platform"? If I want to know if a system is 32-bit or 64-bit, do I ask what "platform" it is?
Next, is what I wrote below correct:
-A 64-bit processor can run a 64-bit operating system or a 32-bit operating system (with a loss of efficiency).
-A 32-bit processor can run a 32-bit operating system only.
If I want to know if a system is 32-bit or 64-bit, do I ask what "platform" it is?
"Platform" is an overloaded term that can mean a great many things. It can mean the CPU family: x86 platform, IA-64 platform, x86-64 platform, ARM platform, MIPS platform, SPARC platform, etc. It can mean the underlying operating system: Windows platform, Linux platform, Solaris platform, etc. It can mean a combination of these: Wintel platform (Windows + Intel). It can mean specific distributions: Debian platform, Slackware platform.
If you want to know if a system is 32-bit or 64-bit, ask if it's 32-bit or 64-bit. And make sure that you also check the CPU for compatibility for your purposes. ARM cores are 32-bit too, but you can't run Windows on them (at this time). SPARCs can be 64-bit, but you won't be running your copy of Microsoft Office on it, I'd wager.
A 64-bit processor can run a 64-bit operating system or a 32-bit operating system (with a loss of efficiency).
This depends very much on the processor. Intel's IA-64 chips can't run 32-bit operating systems because they don't really have 32-bit instructions (if memory serves). About the only way you could run a 32-bit OS on one is if you emulated a 32-bit CPU of some sort. This would suck performance-wise.
On the other hand the x86-64 chips can run 64-bit OSes or 32-bit OSes with no loss of performance at all for the latter (when compared to a pure x86, I mean). I'm running a 32-bit version of Ubuntu, for example, on an x86-64 chip without difficulties. Of course the 64-bit system will run faster than the 32-bit if the underlying software was written to take advantage of the expanded capabilities! (You'd be surprised how little it matters for most day-to-day tasks, though.)
A 32-bit processor can run a 32-bit operating system only.
Again, it all depends on the processor. An x86 (not x86-64) can run 32-bit OSes, but can also run 16-bit OSes right down to plain old MS-DOS. On the other hand, ARMs tend to be 32-bit only. (There are some ARM cores that have 16-bit instructions, but most do not, again if memory serves.)
I'd strike the part about "with a loss of efficiency". 64 bit processors can run 32 bit OS's just fine; with exception to Itanium which require special OS builds.
Efficiency has nothing at all to do with it.
To give a partial answer: 32-bit or 64-bit is part of the architecture. I guess it is part of the platform too, but you're more likely to make an expert think of the 32/64-bit distinction by talking about architecture.
Honestly, if you want to know whether a system is 32-bit or 64-bit, just ask, "32-bit or 64-bit?"
Assuming we mean on bare metal, the second statement is true. The verity of the first depends on the processor architectures. IA-64 processors cannot run IA-32 operating systems without emulation, whereas EM64T processors can.
If you want to know if a system is 32-bit or 64-bit, you could ask what "bitness" it is.
Whether the statements about 64-bit and 32-bit processors running 64-bit and 32-bit operating systems are true depends entirely on which processors and operating systems you are talking about. You won't have much success running Windows XP on an 64-bit Alpha or SPARC processor.