S
Stephen Sprunk
- Jan 1, 1970
- 0
Skybuck Flying said:What amd/intel designed is a REX prefix code which must be placed
before each instruction.
No, that's not how it works.
The 386 added a "mode" bit to the code segment, which made all the
previously 16-bit opcodes work on 32-bit data by default if set. If you
wanted the other size (than what the mode bit specified) you inserted a 66h
prefix byte.
When you go into "long" mode, the default stays 32-bit, but there are prefix
bytes for 16-bit and 64-bit operations if needed. There is also a prefix
byte (usually the same one) to access the additional registers, since x86
only provides three bits for that.
This means that current 32 bit applications have a problem.
They merely need to be recompiled if they were written correctly.
Their instruction encodings are "fixed" and the jumps and the calls are
all "fixed".
It might be possible to convert current 32 bit applications to 64 bit
applications by reading their instruction encodings and trying to insert
rex prefix fields...
However this might create problems where the data structure must remain 32
bit for some compatibility reason.
That's not how code works. The compiler sets the size of various objects at
compile-time, and the code assumes that's the size the objects actually are.
Due to pointer math and such, there is _no_ way to change the size of a
given object after compilation. A program must _always_ remain "compatible"
with itself.
However, since all you should need to do is recompile the program for 64-bit
mode, that's not a big deal. That's how it works on many other OSes that
support both 32- and 64-bit code.
Currently windows can't do this and I know of no tool that can do
this.(Convert 32 bit application to 64 bit application and 64 bit
operations)
No, of course not. It's impossible.
Might I suggest you actually learn how some common CPUs work before
suggesting "improvements" to them? Your past posts indicate you don't even
understand twos-complement math or even how to read a reference manual. Why
waste your time (and ours) proposing changes until you actually understand
what already exists?
My idea works differently:
Instead of inserting the prefix field before each instruction, there is no
prefix field, there are only bitmode variables which indicate what is
supposed to happen to the instruction encodings, these instruction
encodings are more general and can remain the same.
What problem are you actually trying to solve here? It's more productive to
start with that, then try to find solutions, rather than start with a
solution and try to find problems it solves.
Thanks to these bitmode variables the program can alter it's operation
during runtime.
Already exists.
It can change from a 32 bit application to a 64 bit application without
any modifications of it's instructions, only some some variables are
changed in memory which is what programs do all the time.
Compiler writers aren't asking for that, and if they are compiling for
64-bit mode they already have access to 32-bit variables when needed.
Worth a try
No, not really.
S