Flexible Instruction Set Encoding.

So you agree that the current cpu is inflexible.

The data type must be specified at compile time.

The instructions that go with the data type must be specified at compile time.

Which means two different versions have to be created if one of them is to be chosen.

Which creates my problem: two code bases.

Simply creating two binary libraries does not solve it.

The program must use one data type.

Bye, Skybuck.

No, I think the cpu is as flexible as it needs to be.

That's the way statically typed languages work. If you want to use dynamic typing, use a dynamically typed language. But don't expect to get as small or fast code as you could with a statically typed language (though modern dynamically typed languages come fairly close for many applications).

Once you have figured out what you mean by a "data type", you'll understand the situation.

No, your problem isn't two code bases. It is you haven't studied up on what you can do with most programming languages.

Let's start close to the metal.

Now that we have more or less come to consensus that the metal is lacking in features we can go look at programming languages.

Maybe C++ templates might offer a solution but it has it's own drawbacks.

Let me know if you know of any other programming language which can transform one code base into multiple different paths, preferably with debugging support.

Bye, Skybuck.

First of all that check might have to be done rarely.

Second of all cpu's have branch predictors.

Bye, Skybuck.

Python, with psyco to generate machine code if you want it:

Mary Ann?

There is nothing like a consensus on this. The metal lacks no useful features that you have identified. List these features you are claiming.

The C++ templates are just another way to do things. They don't let you determine the type of things on the fly. It is virtual methods that let you do that. The template is really just a way to write a macro. The type gets plugged in and it gets compiled. It is not doing what you seem to think.

C, C++ and Pascal can do what is needed as has been explained. I'm sure that many other languages can too.

Here we go again.

Virtual methods is absolutely not a solution.

It introduces more overhead then the code itself.

Different code paths increases the executable size which is also not nice.

And cpu lacks the possibilities to interpret encoded instructions differently, without actualling having to switch real/protected mode/whatever.

Some day you might get that into your big fat skull LOL.

Bye, Skybuck.

Yes.

There's no reason you could have your program loader substitute the appropriate routines at load time. As-is, program loaders have to do all sorts of "fix ups" (patches) since they generally have no way of knowing what memory location the program will be loaded at; modifying the program loader to play "musical subroutines" isn't that much of a stretch.

If you think about it, just using dynamic link libraries (DLLs) is the same idea, although you're still going through one dereferencing (call) each time you invoke a function.

You have some good ideas, Skybuck, but the other posters who are saying that these are well-known problems with various solutions that have been considered and applied as necessary for decades now are correct. You really should spend some time reading up on computer architecture "through the ages" to learn about how many problems like this have been solved and what the ramifications and "unintended consequences" were. (They're often quite interesting... stuff like how someone thought it would be useful to have a hard drive perform searches for particular data sequences but, as it turned out, it didn't take long before the computer's PC was so much faster than the hard drives that this hard drive "feature" was the slowest way to search, etc. Something very similar happened with the Commodore Amiga computers back in the '80s: Originally the ~8MHz 68000 CPU was "assisted" by what one might call graphics co-processors; just scrolling a line of text on the (graphics mode) screen was done by a blitter. As time went by, Commodore eventually had Amigas with

---Joel

Not all CPUs have them. The fast ones that don't do a few instructions after the one that causes a branch. This can lead to very fast processors but it makes writing for them a bit harder.

No it need not. You are just assuming that the compiler implemented it in a way that takes a lot of time to do. This need not be the case. The syntax of the virtual method, however gives you all the power to explain things to the compiler you need.

If you want code that can do more, generally, you need more code. It takes bits to express the operation to be done.

You are asking for it to switch modes without switching modes. If it does 32 bit or 64 bit operations for the same op-code, there must be a mode switch somewhere.

Insults aren't going to help your argument. They are resorted to by people who know that their position is weak so I know that you are starting to see that you are in error.

Actually no. Virtual methods like all code explain to the compiler what is to be done. The most common way that virtual methods are done is with a call to an element of the VMT. Nothing prevents a smart compiler from unrolling the whole thing to make it like a switch statement etc. The entire section of the routine could be repeated as many times as there are types to handle. This would make it as fast as a manually coded switch statement.

There is software around that does this. It often is very like "self modifying code". An entire set of routines is plugged in based on what is needed.

A classic example of the method is the Borland BGI drivers for DOS based machines. Depending on the graphics card you have, different BGI files get read. These contain the routines for drawing lines etc.

This only works for routines.

Things get difficult with actually accessing data members, which is also related to object oriented programming.

Try writting a base class and derived classess which can access a data type as a int32 or int64 automatically without using a typecast or some kind of virtual function.

At least in Delphi it's impossible !

That makes writing the "write code once" idea impossible.

Not to mention that building two different libraries on the same code as some issue as well and creates a debugging problem.

As far as I know C does not have operator overloading which means using DLL's is useless for trying to find a solution to express math in a generic way. (With the usual symbols: * - + / etc)

Further more you talk s*it.

Show me one solution that works.

I have yet to see one.

Finally I will read the manual about this mode bit that cpu has maybe it's interesting though probably impractical for use because it might crash windows xp ?!?

Bye, Skybuck.

Using a switch per operation is still too much overhead for addition and subtraction.

I tested it yesterday. Overhead is near 33%.

Call overhead method can be even worse.

Bye, Skybuck.

I am pretty sure virtual methods are too slow, even if it's a single switch.

Even if the virtual methods add only one instruction it's still too much overhead !

The only thing that remains interesting is the mode switch.

The insult is also like a joke.

It takes a long time for you for this knowledge to penetrate you brain ! LOL.

Good try resisting it though ! :)

Bye, Skybuck.

For completeness sake there seem to be some exceptions:

From the manual:

Bye, Skybuck.

Where can I find more information about this ?

(Me go search manuals)

Any help/hints would be appreciated.

Bye, Skybuck.

Also I am not sure what you mean with code size ?

If you mean "operand size".

Then AMD probably did not include something like that because the manual clearly says the rex prefix must be used to specify a 64 bit operand size ! ;)

Except for instructions that modify the RSP.

No idea yet what RSP is... 64 bit stack pointer ?

Bye, Skybuck.