I want to implement an emulator for the Raspberry Pi Zero for fun, but I just want to be absolutely sure before I begin, is it the ARMv6 instruction set that is used by Broadcom BCM2835?
From http://elinux.org/RPi_Hardware
CPU core: ARM1176JZF-S ARM11 core clocked at 700MHz; ARM VFP. The ARM11 core implements the ARMv6 Architecture. For details on ARM instruction sets and naming conventions, see ARM architecture and List of ARM microprocessor cores
The Pi3 uses a later chip but that can still do ARMv6
Related
I upgrade my cPCI board to an adlink-3970 (PCI 3.0). The machine boots up to windows, all the drivers are installed correctly including the my PCI 2.1 device's driver (meaning the CPU was able to read the ROM over the PCI bus). However, when I try reading data from my PCI 2.1 device, all the registers read 0. Are these two boards not compatible?
More info:
I've read that they should be compatible and the electrical/mechanical specs indicate that they are. I've also tried swapping in for another CPU board but with the same results. The only difference in the upgraded board is that the CPU uses a PCIe-PCI bridge to communicate on the PCI bus. I'm wondering if that's the issue.
PCIe is backward compatible. A PCIe3.0 card will work on a PCIe2.0 slot.
Hello Humble Stackoverflow users,
According to this XEN article, PVH mode keeps all components paravirtualized except Pagetables - "but instead of requiring PV MMU (often called paravirtualized page tables), it uses the HVM hardware extensions to virtualize the pagetables".
Accoring to link i've provided above and wiki, you can learn that Pagetables are heavily connected with CPU workflow. However, following article sais that HVM hardware Extensions are providing CPU virtualization - "Technically speaking, HVM refers to a set of extensions that make it much simpler to virtualize one component: the processor."
At the end all this left me in confused state.
Does XEN PVH mode requires Intel VT-x or AMD-V HW virtualization or not?
Regards,
Leshcat
pvh only works with intel vt for now and there is no support for 32bit guests yet, as you can see in the readme
http://xenbits.xen.org/docs/unstable/misc/pvh-readme.txt
Following remain to be done for PVH: AMD port.
https://blog.xenproject.org/2015/01/15/less-is-more-in-the-new-xen-project-4-5-release/
PVH initial domain support for Intel has been added and now supports running as dom0 and FreeBSD with Linux platforms
I recently have acquired a Apple G5 computer (PPC 970) and am interested in learning more about the PowerPC architecture (most of my systems programming knowledge comes from x86 and my own hobby kernel).
After using the computer a while and getting used to PowerPC assembly (RISC), I noticed that low level CPU virtualization is not possible on PowerPC 970 based Macs. The CPU in documentation (PowerPC 64) seems to support hypervisor mode, but it has been noted that it is not possible due to Open Firmware.
Do all operating systems which are loaded from Open Firmware on PowerPC 970 series Macs load in hypervisor mode, making "nested" virtualization impossible? If this is true, why does Open Firmware load all Operating systems in hypervisor mode? Is this in order to provide a secure layer for communication between the the Operating System and Open Firmware (using firmware for everything except ACPI and memory discovery during boot, which requires a transition into "real-mode", is unsafe in x86?).
Also if the Operating system were using hyper-calls to facilitate a secure transition to firmware based routines, wouldn't this impose a large penalty just as syscalls do?
I'm not privy to Apple's hardware designs, but I've heard that the HV mode (ie., HV=1 in the Machine State Register) was disabled, through hardware, on the CPUs used in the G5 machines.
If this is the case, then it's not up to the system firmware to enable/disable HV mode - it's simply not available.
At the time that these machines were available, other Power hardware designs had a small amount of firmware running in HV=1 mode, and only exposed HV=0 to the kernel. However, the G5 wasn't one of these.
I frequently encounter these terms and am confused about them. Are they specific to the Processor, or the Operating System, or both?
I have Ubuntu 12.04 running on Intel i7 machine. So which one of them would apply for my case?
They are processor instruction set names:
i386 is the name of the 32-bit instruction set first implemented by Intel in the 386 processor. It became dominant thanks to dirt-cheap PC hardware.
x86-64 is the name of the AMD extension added to i386 to make it capable of executing 64-bit code. This is the one you have. It is highly compatible with i386 and will execute a 32-bit program as fast as an i386 processor.
ia64 is the name of the instruction set used in Itanium processors. The other 64-bit architecture that nobody uses anymore.
Those are cpu instruction sets. Apps installers are compiled to some subset of them. Here most difference is between 32bit(i386) and 64bits(x86_64 and ia64). You can not run app for 64bit on 32bit cpu but in reverse usually yes.
x86_64 (AMD64) cpu is most common instruction set as comes to 64bit cpu on desktop computer. It is from AMD which was few years earlier with their cpu which worked fine with x86(32-bits) instructions also.
ia64 (itanium) is from intel. Itanium works fast only with 64bits and is still used in industry.
Intel now uses x86_64 instructions from AMD due to its popularity in industry.
Sometimes key "amd" at installer package name is present and it is what you need for 64bit intel cpu.
i386 is quite old (Pentium times, pentium III has i686). To determine 32bits architecture(on desktop computers) also is used term x86 (aliases: IA-32, x86-32). There are also other architectures 32/64bit like ARM from smartphones.
Other cpu instruction sets can make compression, video coding/decoding, virtualization, random generators, security etc. to be faster and better. Windows 8 require PAE, NX, SSE2 (some of those are not present in ARM cpus so you have other version of Windows 8RT for them).
In hardware, x86_64 is a type of processor that can run both 32bit and 64bit applications just fine where ia64 runs 32bit applications SLOWER than any other CPU, as it is meant for 64bit only applications.
Moving on to the software side. I'm not sure about Ubuntu, but generally a 64bit Windows OS will allow you to use more than 3.3GBs of memory as well as the advantage of using your 64bit hardware to address memory better and have bigger than 2GB processes running. Usually on a 32bit, once an application reaches the 2GB limit, you'll get a OutOfMemory error from your application.
For a full article, refer to: http://en.wikipedia.org/wiki/64-bit_computing
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.