I guess the question is about PC based (Windows, Non-Macintosh) processor Architecture Design and open use. Is there a "Standard Interface" (byte-code) for PC machines, aside from processor specific optimizations, available to the public and can be used for (General) Custom Kernel Designs and Operations and OS Development. I would also like to go as far to ask if PC based machines have standard interfaces for drivers as well. Is driver design OS specific or based solely on a compatible machine (which I would guess 'could' be x8086 or x64, heap, stack, and memory consumption). I hope this is the right place to ask this question. I'm not so much concerned with .asm or .o at this point as much as I'm concerned with graphics, sound, ports, and underlying OS. Unless Windows releases a Universal Assembler and Compiler (byte code-specific) interface, but from what I've read, I think it's different on different machines and is largely based on the Kernel used. Please correct that if it's wrong.
There is but it may not be what you imagine it to be. There is a point at which software abstractions end. The "standard interface" is described by Intel's datasheets for the processor. It tells the behavior of the chip and it is indeed byte code. The thing is programmed by setting up a piece of memory with instructions. An instruction could be a byte telling it what to do followed by a number of operands.
That is what an OS kernel developer has to work with. I can think of a number of reasons why there is no generic "operating system SDK".
- The market for such a product would be very small;
- abstraction and generalization are expensive and we are talking about a level at which every clock tick counts;
- an operating system SDK would basically be an OS kernel.
It has been done mind you (although not for the general public), when Microsoft started developng Windows NT they started out by "doing it right" and they had this thing they called the HAL, the hardware abstraction layer. They also isolated video hardware completely from the OS. It was perfect, apart from one little problem, it performed miserably. So they soon started to cut some corners and moved away from the clean design to make it usable.
As for drivers, those are OS specific on the one end and the other end is too diverse and hardware specific for a common layer to be of any use.
Is there a standard byte code interface for x86/x64 processors?
Yes, the term you are looking for regarding byte code of (hardware) processors is called:
- Instruction Set Architecture, commonly abbreviated as ISA, which defines how the processor works across all chips of the produce line, old to new, slow to fast (though there are always instruction set extensions to concern oneself with each newer generation of chips).
I would also like to go as far to ask if PC based machines have standard interfaces for drivers as well.
Yes, windows OS has a broad set of standard interfaces for drivers at various levels of abstraction. Windows & linux differ in driver interfaces, so a driver for one won't drop into the other.
Is driver design OS specific or based solely on a compatible machine (which I would guess 'could' be x8086 or x64, heap, stack, and memory consumption)
Yes, each operating system defines another interface layer called:
- Application Binary Interface, commonly abbreviated as ABI, which defines how to access various operating system services within the context of a choice in operating system and also an ISA.
The ABI is pretty broad and covers things like calling convention, operating system calls, and a host of other things.
And for example, Windows and Linux define different ABIs, in particular, for example, the calling convention is different even for the same generation of processor (e.g. x64). The calling convention dictates how parameters are passed; how values are returned; how stack frames are created, unwound on exception, etc... Other parts of the ABI define how library function (say in DLLs) are located; how binary executable images are formatted, etc..
On top of the ABI, operating systems define frameworks, typically, of system calls and an libraries, (such as Dynamically Linked Libraries in what's called:
- Application Programming Interface, commonly abbreviated as API.
Firmware and hardware (think BIOS and IBM-PC)
The instruction codes in a compiled program must, of course, match the instruction codes of the processor. But that is not enough. The program may want to interact with some hardware, like a display, loudspeaker, network, keyboard, etc. They have specific I/O addresses in the hardware. The program needs to send the right bit-patterns to the right addresses. If there is an OS or a BIOS, the program may just call the appropriate API. Then the OS, the BIOS or the drivers will interact with the hardware.
A compiled program thus assumes not only a processor, but also what hardware, firmware, or operating system, it will run on.
There are standards for operating system API (e.g. Posix, Win32, Elf), for firmware API (e.g. BIOS, UEFI) and for hardware (e.g. < ? >).