-If u have a slower I/O unit, then can the CPU execute instructions while waiting on slower I/O?
-In this case, this type of optimization works differently for different I/O units...
-So why are there no smarter .exe files that orders the instructions for your I/O-usage?
-Whouldn't that be a great optimization?

If you mean why the compiler doesn't reorder those instructions to optimise, its simply because compilers don't know what the hardware is. Most I/Os require some things sequenced which cannot be reordered.

No of course the .exe, because from this "perspective" we can "see" the speed of the I/O...

& by the way why increasing to 64-bits? Why not increase the size of bytes with 1 bit? Is that so terrible? I think 64-bits is really terrible...
(Because it was increased because of bigger mem-space in the future, huh?)
I at least can't see any purpose in making 64-bit calculations...

Hmm... Maybe I should take patent of this solution.. haha! But this is too simple -- there must be a cause!!!

Maybe you should explain with you mean by "perspective" I'm not really sure what you mean. How would you "see" the speed of the I/O instructions?
I'm not sure what you mean by increasing size of bytes with 1 bit.

Simply to calculate more precised numbers or largers numbers, for architectural reasons is necessary if the address bus is 64 bits wide so that the cpu can access all avaible addresses. In the x86 architecture with EM64T, theres no need for you to do 64 bit computing if you don't have to, but if you wish to, theres no performance penality from 32bit computing. Whereas on a 32bit processor, which require extra clocks to do 64 bit computing.

You can make an I/O call and then continue to compute unrelated code. However, the case often arises where the unrelated code is completed before the I/O, and then the CPU is essentially waiting. Then again, with OS process scheduling, this is pretty minimal. On a related note, this was one of the main considerations for the Hyper-Threading design in P4 processors (where a second thread could be executed while the first was waiting for something).

Take a hardware design class. Sounds like it could be useful... a 33-bit design would be really messy to work with, and hardly of any benefit over 32-bit.

How would you "see" the speed of the I/O instructions?
You measure the time it takes to use a I/O unit. But I found that it takes different times to access a non-standard I/O unit at different states... So you have to just think of the standard I/O when you are programming: harddrive, RAM, disks, graphics card...

& I mean if we have adresses to bigger objects than 1 byte, we can store more in this object, instead of increasing the adress-space to increase the maximum memory storage.


In the x86 architecture with EM64T, theres no need for you to do 64 bit computing if you don't have to, but if you wish to, theres no performance penality from 32bit computing. Whereas on a 32bit processor, which require extra clocks to do 64 bit computing.

Yes, but it will cost other things of course... It is true if the semicunductors is smaller, or voltage & clock-rate higher.
& there must be more semiconductors on a 64-bits CPU.
Or something that I doesn't understand. But thanx for this reply.

But I whould like 9-10 bits memory units instead.