Flexible Instruction Set Encoding.

[Skybuck Flying]

Oh wait that was steven who wrote rex prefix is for extra registers.

The rex prefix is also necessary to specify the operand size is 64 bit !

The manual says so

Bye,
Skybuck.

 

[Skybuck Flying]

If you only followed my advice you might have learned something it's not

You actually managed to get something correct. Congratulations; it's
rare.

You are learning that's good.

No, the REX prefix is necessary to access the additional registers; that's
why it's named the Register EXtension prefix. The beauty of long mode is
that the CPU works the same way whether you want 32- or 64-bit math, and
they run at the same speed. Only loads and stores require any additional
work (to mask off the top 32 bits), and you _have_ to recompile to change
from 32- to 64-bit data types because the amount of storage (and thus
pointer math) for an object will change. If you don't understand why, you
need to go study assembly language more before suggesting complicated and
unnecessary modifications to CPUs.

Again you are wrong, to bad for ya, better reading next time !

From the manual:

"
2.2.1 REX Prefixes
REX prefixes are instruction-prefix bytes
.. Specify GPRs and SSE registers.
.. Specify 64-bit operand size.
.. Specify extended control registers.

Not all instructions require a REX prefix in 64-bit mode. A prefix is
necessary only if an instruction
references one of the extended registers or uses a 64-bit operand. If a REX
prefix is used
hen it has no meaning, it is ignored.
"

Notice have it clearly says, uses a 64 bit operand, and 64 bit operand size
!

Good luck next time !

Actually, AMD invented it and everyone else copied. I trust their chip
designers' judgement about how best to skin this cat more than someone
who's shown they are incapable of even comprehending the existing manuals
or twos-complement math.

You write many insults for somebody that has been wrong many times.

Bye,
Skybuck.

 

[Skybuck Flying]

Actually, only 2 and 3 are relevant here, because you first have to figure
out if you need 32-bit or 64-bit data. If you don't know that, then your
problem is either not well enough specified for you to start coding, or is
so vague and general that you are better off using abstract types rather
than fixed sizes (and probably better using a language such as Python,
which has direct support for arbitrarily long integers, and can be
combined with psyco to generate reasonably good machine code on the fly).

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.

 

[David Brown]

So you agree that the current cpu is inflexible.

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

The data type must be specified at compile time.

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

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.

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

 

[MooseFET]

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.

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

 

[Skybuck Flying]

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.

 

[Skybuck Flying]

That logic is already there; the same opcodes are used for 16-, 32-, and
64-bit operations. The opcode for 8-bit operations is typically only
different by one bit.

The problem, which you keep refusing to acknowledge, is that you can't
load or store data of indeterminate size because the compiler (or assembly
coder) needs to know how much space to reserve for objects at compile
time. And, of course, loads are by far the biggest consumer of CPU time
in a typical application -- some spend up to 80% of their time waiting on
memory. Worrying about a few extra _nano_seconds to execute emulated
64-bit operations on a 32-bit machine is pointless when that same machine
just waited tens of _micro_seconds for the data to show up. Any
unpredictable branches, like doing run-time checks on data to see whether
or not to use emulation, will stall the pipeline and cost up to tens of
microseconds again to save a few nanoseconds of execution time.

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

Second of all cpu's have branch predictors.

Bye,
Skybuck.

 

[David Brown]

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.

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

http://psyco.sourceforge.net/

 

[krw]

Well, he WAS on that island for 30 years, after the shipwreck and he
WASN'T the professor.

Mary Ann?

 

[MooseFET]

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.

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

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

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.

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.

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

 

[Skybuck Flying]

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.

 

[Joel Kolstad]

Virtual methods is absolutely not a solution.
It introduces more overhead then the code itself.
Yes.

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

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
68030 CPUs running at 25MHz... still coupled with the 8MHz custom chips. At
that point, it was noticeably faster to have the CPU do the blitting rather
than the co-processors!)

---Joel

 

[MooseFET]

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

Second of all cpu's have branch predictors.

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.

 

[MooseFET]

Here we go again.

Virtual methods is absolutely not a solution.

It introduces more overhead then the code itself.

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.

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

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

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

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.

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

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.

 

[MooseFET]

Yes.

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's no reason you could have your program loader substitute the
appropriate routines at load time.

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.

 

[Skybuck Flying]

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

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.

 

[Skybuck Flying]

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.

 

[Skybuck Flying]

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.

 

[Skybuck Flying]

For completeness sake there seem to be some exceptions:

From the manual:

"
2.2.1.7 Default 64-Bit Operand Size
In 64-bit mode, two groups of instructions have a default operand size of 64
bits (do not need a
REX prefix for this operand size). These are:
• Near branches
• All instructions, except far branches, that implicitly reference the RSP
"

Bye,
Skybuck.

 

[Skybuck Flying]

Where can I find more information about this ?

(Me go search manuals)

Any help/hints would be appreciated.

Bye,
Skybuck.