Flexible Instruction Set Encoding.

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.

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?

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...

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

Something must be changed...

Bye, Skybuck.

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

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.

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.

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.

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.

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.

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.

You say this and then suggest:

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

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.

1. 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 f*ck 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.

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

We all know that one LOL.

Bye, Skybuck.

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.

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.

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.

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.

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

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, ...).

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...

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.

Enjoy the epiphany :)

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).