Flexible Instruction Set Encoding.

[Stephen Sprunk]

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

 

[Stephen Sprunk]

The whole idea for the variable BitMode is SPEED.

Constantly/dynamically having to add a REX prefix or whatever doesn't
sound FAST.

The decoders don't have any throughput difference for instructions using a
REX prefix vs ones that don't. There might be minor instruction cache
effects, but you're going to pay that price anyways to get access to the
additional registers, and that usually provides more of a performance boost
than not using REX at all.

Setting a BitMode variable just once SOUNDS FAST =D

What sounds fast often isn't. You remind me of those kids who put stickers,
spoilers, neon, etc. on their little 1.6L front-wheel-drive cars. None of
that makes them go faster, but it makes the owner feel better about his 0-60
time of 15 seconds. The car _looks_ fast, right?

S

 

[cr88192]

What amd/intel designed is a REX prefix code which must be placed before
each instruction.

This means that current 32 bit applications have a problem.

alt.lang.asm included to newsgroup, maybe they know if this is possible,
find it interesting or maybe they go investigate

well, it is not not possible as stated.


however, I before considered the (hypothetical) idea of an
emulator/psuedo-JIT for driver backwards compatibility, which would
recompile x86 machinecode into x86-64 machine code partly through emulation.
hypothetically such a thing would be used to try to keep older drivers still
working.

of course, such an emulator would likely need to be integrated into the
kernel, or as a kernel module, and would likely involve conversion stubs for
nearly any code or data used by the driver (since the memory layout is
almost invariably different, a great problem becuase many OS's keep end up
with drivers directly manipulating structs).

but, there is a lot that would go into this, not at all something easy or
automatic.
if it were at all possible to port/recompile, that is a better option.

a slight variation would actually be to run a whole 32-bit mini-kernel in
the emulator, the drivers effectively living in the fantasy that they are
interacting with a real kernel, with basically special hook interfaces set
up to allow interaction with the outside world (the kernel knows it is fake,
so it knows to use such interfaces).

the analogy here would be like running VMware. the user can still use an
app, but damn near the whole world this app operates in lives within the
emulator.

most real 64-bit OS's, simply discount 32-bit driver support.


a few (such as MacOS on x86), often use such emulators to retain
compatibility with older software though...

or such...

 

[Skybuck Flying]

And how does it recompile for 64 bit without changing the code ?

Something must be changed...

Bye,
Skybuck.

 

[Chris Thomasson]

And how does it recompile for 64 bit without changing the code ?

Something must be changed...

Why? I can compile a lot of 32-bit SPARC code for a 64-bit SPARC CPU if I
don't use DWCAS?

 

[Skybuck Flying]

Please explain how you think the rex prefix works.

What I want to achieve is:

The program analyzes the goal.

The program figures out the number of bits required is 32 bits or less.

The program than simply uses one single 32 bit instruction to perform moves,
add, multiplications, divisions etc.

If the program figures out the number of bits required is 64 bits or less
but greater than 32 bits the program uses

Multiple 32 bit instructions to simulate 64 bit.

For example two adds and add with carry is needed to simulate a 64 bit
instruction.

This should all happen during runtime and pretty fast too, recompiling is
ofcourse undesirable because this would require the source code to go with
the program and the compiler binaries and the recompile could take long
depending on the high level language used.

The benefit is clear:

For the 32 bit case only single instructions needed, more speed !

For the 64 bit case only a few extra instructions needed to simulate 64 bit
instructions, still pretty good speed.

While still remaining backwards compatible with current 32 software and
operating systems.

Bye,
Skybuck.

 

[Skybuck Flying]

Well if it's not possible with the current instruction set than my idea
becomes pretty interesting !

No need for complex solutions.

Just a few buildin if statements inside the compiler which examines a bit
mode and voila !

Bye,
Skybuck.

 

[Skybuck Flying]

There is only one way to perform 64 bit operations on 64 bit data and that's
by using the rex prefix.

There is however a "mode" which is called 64 bit mode, however if you read
the manual then you would have learned that even in 64 bit mode, the default
size is still 32 bits !

That's why the rex prefix code is necessary to get true 64 bit operations.

Bye,
Skybuck.

 

[MooseFET]

And how does it recompile for 64 bit without changing the code ?

Something must be changed...

The GCC compiler is very smart about such things. It can compile the
same C on my home machine as my work machine.

Ypu need to read up on what already has been done.

 

[MooseFET]

Why? I can compile a lot of 32-bit SPARC code for a 64-bit SPARC CPU if I
don't use DWCAS?

You could also compile a lot of the code I'm running on my x86_64 with
no changes. Writing portable code can be done in C if you willing to
do all the extra work.

 

[MooseFET]

Well if it's not possible with the current instruction set than my idea
becomes pretty interesting !

No, your idea isn't interesting. All the useful things are done by
the existing methods. I can run the code I need to run and can use
the 64 bit and the 32 bit code without trouble so your idea doesn't
add anything. You need to suggest a real problem and then find a good
cure for it.

No need for complex solutions.

You say this and then suggest:

Just a few buildin if statements inside the compiler which examines a bit
mode and voila !

which is going to be more complex than what is already done and yet it
leads to no advantage.

 

[Skybuck Flying]

I also want backwards compatibility with current 32 bit hardware and
operating systems.

Switching to 64 bit mode where extra registers and maybe new instructions
would be used would break compatibility.

So even these new flexible instructions would break compatibility, so this
discussion is probably pointless except maybe for the future.

But then again if I want compatibility mode... I wonder if it would be
interesting.

The cpu would have to do two adds and an add with carrie for 64 bit
simulation.

Would this be interesting for cpu makes to implement ?

Probably not... or maybe it would still be interesting... I don't know.

If this would make software automatically scale then people might be
interested.

However then intel could have implemented it already by writing:

OperationSize := 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 bytes whereever you
want to place the limit.

OperationCode...

Then the cpu does the operation is good as it can with it's current
resources.

Unfortunately intel thought 32 bit was enough, for now it is... but for how
long ? not that long I think

For some things it is already not enough like file system stuff.

That's what I need it for mainly...

However I shall have to examine the code more...

Maybe it only requires 64 bit data transfers and 64 bit adds and subs...

That could be done with 3 instructions instead of 1... but then again other
parts of the program need to be 64 bit as well...

So still many parts need to be 64 bit I think... so it could become a slow
down issue... like twice or three times, maybe even 5 or 6 times as slow...

Don't know yet...

I am not happy that my program will slow down if I convert if from 32 bit
mode to 64 bit simulated mode.

Real 64 bit mode is not option yet, many people don't have it, and I really
want my program to work on 32 bit with 64 bit emulation as well.

I would like to keep my program 32 bit fast as well though.

And I would like to keep the source code in one version.

Two versions sux, three versions would be even worse.

The pain is clearly feelable

Current options looking bad:

1. Switch to real 64 bit, result: many systems won't be able to use it.

2. Switch to emulated 64 bit, result: slower program.

Absolutely no option available to keep source code the same without wacky
constructs like ifdefs, or whatever.

Only solution so far might be might presented solution and implement it as
operator overloading... this will slow down the program even more because of
all the if statements... which makes switching between 32 and 64 bit
pointless... because than the 32 bit mode will become slower as well.

Not to mention possible 16 bit modes...

Just in time compiling could be a solution but this requires the source to
be available or byte code to be available which is easily reverse
enginerable.

The concepts of a computer and math are pretty simple, basic math is even
thought to school kids of 7 to 14 years old.

How intel managed to **** up the world so much is beyong my comprehension
lol.. no just kidding.

It was all about speeeeed. Who had the fastest CPU ?!

They didn't care about backwards compatibility... sure their cpu's were
compatible but only in certain modes....

Not in the higher 32 bit modes or een 64 bit modes...

You want the new modes... change/upgrade and recompile your code they say !

Hehehe...

Tell it Albert Einstein to recompile his E=MC2 formula !

Ludicrious !

Bye,
Skybuck.

 

[Skybuck Flying]

Actually they didn't care about future compatibility or scalability.

We all know that one LOL.

Bye,
Skybuck.

 

[Skybuck Flying]

Give an example.

Write me some C code that does some 32 bit or 64 bit calculations at runtime
without too much overhead.

I would be very intested in such a thing/concept !

Some links would be very usefull and greatfull too, because I don't think it
even exists... but apperently you know something I don't know... please
share and enlighten me LOL.

Bye,
Skybuck.

 

[Skybuck Flying]

Show us a simple C example which will compile once and can scale from 32 bit
operations to 64 bit operations at runtime based on some control word or
some conclusion/decision.

Bye,
Skybuck.

 

[Skybuck Flying]

I don't know about all that old shit.

I just look at the intel shit.

Apperently intel didn't know that old shit as well.

Apperently microsoft didn't know that shit as well.

They both created a non runtime scalable architecture and microsoft
implemented an operating system based on it and had to rewrite and recompile
must of it it seems, same goes for the driver writes.

Unless ofcourse those old systems you talk about aren't really scalable
computers...

I don't know what the thruth is about the old systems... all I know is the
current system are non runtime scalable that's for sure.

Bye,
Skybuck.

 

[Skybuck Flying]

Yeah,

If you do happen to produce a code sample, Bill Gates and Intel will be most
interested since I am sure they pulled their hair out when they tried to
scale their architecture and their operating system to 64 bit.

And we all know windows xp 32 bit and even windows xp 64 bit ain't scalable
at runtime.

Intel and Microsoft are great companies for binary plug ins and such but not
for binary runtime scalability !

You want more, you gotta buy new stuff, write new stuff, compile new stuff,
modify a whole lot of things, get new drivers yadadadadaa , install all that
stuff LOL.

Bye,
Skybuck.

 

[cr88192]

Well if it's not possible with the current instruction set than my idea
becomes pretty interesting !

No need for complex solutions.

problem is, mixing 32 and 64 bit code, absent complex solutions (such as
emulation), is not possible. would have been nice if it were, but partly I
blame AMD for this one (it is, really, a whole hell of a lot easier to mix
16 and 32 bit code than it is 32 and 64...).

so, as a result, we have 64 bit OS's with IMO fairly bad backwards
compatibility (old drivers don't work, lots of existing software is broken,
....).

Just a few buildin if statements inside the compiler which examines a bit
mode and voila !

depends on what you mean by this.

if you mean, making the compiler able to target one arch or another, this is
a little easier, but still, not as you describe (really, having a
multi-target compiler is a bit more "involved" than simply
inserting/removing prefixes, or even renaming registers and chnging type
sizes). you have to deal with the fact that a whole bunch of crap is subtly
changed around and has to be reworked (most annoyingly in my case, that
x86-64 uses somewhat different calling conventions than x86).

this is why my compiler does not support x86-64 yet. didn't get around to
adding all the needed stuff...

or such...

 

[SpooK]

AMD64 Volume II, Chapter 2, Section 2.1.

"Compatibility Mode. Compatibility mode allows 64-bit operating
systems to implement binary compatibility with existing 16-bit and 32-
bit x86 applications. It allows these applications to run, without
recompilation, under control of a 64-bit operating system in long
mode. The architectural enhancements introduced by the AMD64
architecture that support compatibility mode are summarized throughout
this chapter."

AMD64 Volume II, Chapter 1, Section 1.1.3.

"Compatibility mode, a submode of long mode, allows system software to
implement binary compatibility with existing 16-bit and 32-bit x86
applications. It allows these applications to run, without
recompilation, under 64-bit system software in long mode, as shown in
Table 1-1 on page 11.

In compatibility mode, applications can only access the first 4 Gbytes
of virtual-address space. Standard x86 instruction prefixes toggle
between 16-bit and 32-bit address and operand sizes.

Compatibility mode, like 64-bit mode, is enabled by system software on
an individual code-segment basis. Unlike 64-bit mode, however,
segmentation functions the same as in the legacy-x86 architecture,
using 16-bit or 32-bit protected-mode semantics. From an application
viewpoint, compatibility mode looks like a legacy protected-mode
environment. From a system-software viewpoint, the long-mode
mechanisms are used for address translation, interrupt and exception
handling, and system data-structures."

There is a slightly uncomfortable procedure required to absorb
information like this on your own. The basic steps are outlined below.

1) Remove head from ass.
2) Open eyes.
3) Read.
4) Think.

Enjoy the epiphany

 

[cr88192]

While still remaining backwards compatible with current 32 software and
operating systems.

you may want to consider bytecode or some kind of IL, and JIT, as a possible
option.

for example, .NET can target both 32-bit and 64-bit with the same binary.
how? the .NET bytecode as such does not care so much about the exact
architecture.

so, when being run, the JIT compiler converts said bytecode into something
that will actually run on said architecture...

similar should also be possible with the JVM (although slightly less
cleanly, as the JVM is a little less abstract said .NET...).


actually, this had originally been my goal, but my result (RIL), presented
some issues, and early on I switched from bytecode to a serialized ascii
representation (a language, all in all, vaguely similar to postscript).