Some general questions about computer science....
1.How does the CPU know what/where to write the bytes to the system bus or memory mapped region to send data to I/O devices, like graphics cards, PCI cards, etc(Especially since it can vary between chipset and hardware).
2.If a CPU has a faster clock it theoretically will perform a fetch, decode, execute, and write-back faster.
3.You can see the internal registers inside of a microprocessor with a micrograph.
2.If a CPU has a faster clock it theoretically will perform a fetch, decode, execute, and write-back faster.
3.You can see the internal registers inside of a microprocessor with a micrograph.
In software it depends on the instruction set architecture. In hardware it depends on the physical "hardware" architecture. It can be quite complicated because there are different architectures: Stack-based, Accumulator-based, and Register-based, and on modern machines, a mix.
1. In general the ALU and MMU (if the MMU is not on the ALU) will handle this. In theory, (hardware-wise) It will calculate the physical address of the correct memory cell in ram. In software the cpu will decode the current instruction (or past instruction) that has been read from memory. What is decoded from the instruction is an address and an opcode. The address part of the instruction will be used to tell you what memory cell (physical memory) will be read or written to, OR if the address part is a value, the value will be operated on. The opcode part will tell the Control unit what to do next, like adding or subtracting.
2. Yes, but there is risk to that, because there can be a propagation delay. Because if a cpu goes at a faster rate than when it can properly submit data to the proper registers you can damage your computer and what you intend to happen will not be fully complete. You have to have your CPU properly synced within the limits of the motherboard's system bus. Otherwise components that the CPU accesses like device controllers (devices that interface withl RAM, Keyboard, Monitor) will behave with unintended results or not at all, depending on the data that the cpu feeds it through the bus control lines.
3. not a question, not sure what you are saying.
1. In general the ALU and MMU (if the MMU is not on the ALU) will handle this. In theory, (hardware-wise) It will calculate the physical address of the correct memory cell in ram. In software the cpu will decode the current instruction (or past instruction) that has been read from memory. What is decoded from the instruction is an address and an opcode. The address part of the instruction will be used to tell you what memory cell (physical memory) will be read or written to, OR if the address part is a value, the value will be operated on. The opcode part will tell the Control unit what to do next, like adding or subtracting.
2. Yes, but there is risk to that, because there can be a propagation delay. Because if a cpu goes at a faster rate than when it can properly submit data to the proper registers you can damage your computer and what you intend to happen will not be fully complete. You have to have your CPU properly synced within the limits of the motherboard's system bus. Otherwise components that the CPU accesses like device controllers (devices that interface withl RAM, Keyboard, Monitor) will behave with unintended results or not at all, depending on the data that the cpu feeds it through the bus control lines.
3. not a question, not sure what you are saying.
Last edited on
I think you misunderstood, but thanks for the insight anyways.
As for number one, here is a revised question:
1.How does the microprocessor write the bytes that will be appearing in video memory to a video card without knowledge of what video card it is going to be writing to? Say I place a PCI Radeon card and boot without any other onboard hardware, and expect to write to the card to show screen data. What specification would circumvent the differences in cards and the differences in how the instructions to write to the cards would be carried out in the bit level?
The microprocessor has no knowledge of what it's writing to, and what it's writing to will have different registers/stack, memory layout, etc.
Theoretical example, super simplified:
CPU BOB
INSTRUCTIONS:
BYTE 0x0EFF <-- We'll call this the data for one pixel, one bit, theoretically.
BYTE 0x00FF <-- We'll use this as the position to represent the pixel.
Assume that these bytes are expected to work on one card specifically, how would you determine what ordering method would circumvent a different card altogether in terms of machine instructions, or any compiled/assembled code to represent the same instructions?
As for number one, here is a revised question:
1.How does the microprocessor write the bytes that will be appearing in video memory to a video card without knowledge of what video card it is going to be writing to? Say I place a PCI Radeon card and boot without any other onboard hardware, and expect to write to the card to show screen data. What specification would circumvent the differences in cards and the differences in how the instructions to write to the cards would be carried out in the bit level?
The microprocessor has no knowledge of what it's writing to, and what it's writing to will have different registers/stack, memory layout, etc.
Theoretical example, super simplified:
CPU BOB
INSTRUCTIONS:
BYTE 0x0EFF <-- We'll call this the data for one pixel, one bit, theoretically.
BYTE 0x00FF <-- We'll use this as the position to represent the pixel.
Assume that these bytes are expected to work on one card specifically, how would you determine what ordering method would circumvent a different card altogether in terms of machine instructions, or any compiled/assembled code to represent the same instructions?
Last edited on
closed account (zb0S216C)
Video memory normally starts at specific addresses which are either 0xA0000, 0xB8000 or 0xB0000 as it depends on the graphics mode. The CPU doesn't really care which address it read/writes to so long as the address is within range (in 16-bit real-mode, addresses greater than 65,535 are not accessible, thereby limiting the CPU to 1MB of addressable memory) and that it [the CPU] can write to that address (not ROM).
Wazzak
Wazzak
Last edited on
| Correct me if I'm wrong, but doesn't the GPU handle most of this? |
The GPU will only do what the CPU (If they're separate) tells it to do.
In most cases the bootloader will access memory that's mapped in address space to display data, and then by the time an OS is loaded, a driver will get full power over all of the memory, 3-D optimizations and rendering advancements, etc(BIOS or EFI/UEFI firmware can use the GPU as well).
A lower-end GPU is the same thing, but there's less memory, performance units, and speed, as well as 3-D calculation support and the like.
The difference between a high-powered GPU and a low-end onboard one to an Amiga chip is, well, performance, memory, and units(and capability).
So yes, the GPU does handle most of the graphics data within its firmware, registers/stack, units, etc. But the CPU or main processor will be the top dog as always.
Last edited on
Topic archived. No new replies allowed.