Flexible Instruction Set Encoding.

[Skybuck Flying]

Hello,

Some parts of the computer program could benefit from being flexible for
example:

If the some parts of the computer could turn itself from 32 bit into 64 bit
at runtime that could be very handy, then that code does not have to be
re-written or added, it's simply the same code/instructions.

However other parts of the program must remain compatible with todays
designs which could require 8 bit, 16 bit, 32 bit data types and
instructions.

So the idea is to extend the current intel/amd instruction set with a
flexible instruction set encoding it works like this:

The CPU has an extra variable for example called "BitMode".

The BitMode is set to whatever the section of the code needs for example 16
bit, 32 bit, 64 bit.

It might also be pushed onto the stack so that each procedure could actually
have it's own BitMode, so that procedures can even call other procedures
with mixing things up.

Then the new flexible instruction encoding examine this variable.

The CPU then does the following "underwater":

Let's first give program example:

instruction: SetBitMode, 64
instruction: move register A, register B
instruction: add register A, register B
instruction: compare register A, register B
instruction: jumpifgreater to etc.

Now what the cpu "underwater" does is for each instruction is:

// first move instruction:

if BitMode = 8 then
begin
mov8bit register A8bit, register B8bit
end else
if BitMode = 16 then
begin
mov16bit register A16bit, register B16bit
end else
if BitMode = 32 then
begin
mov32bit register A32bit, register B32bit
end else
if BitMode = 64 then
begin
mov8bit register A64bit, register B64bit
end;

// second add instruction:

if BitMode = 8 then
begin
add8bit register A8bit, register B8bit
end else
if BitMode = 16 then
begin
add16bit register A16bit, register B16bit
end else etc


I just had this idea, I didn't try coding it in Delphi (with operator
overloading or whatever).

But ofcourse I can already see that if I would code this with existing
instruction sets all the if statement could/would (?) Kill performs
somewhat...

I might not even be that bad compared to other solutions... but there is
still some overhead.... Maybe a lookup table and calls might help who knows
?

For example:

BitMode = 0; // 8 bit
BitMode = 1; // 16 bit
BitMode = 2; // 32 bit
BitMode = 3; // 64 bit;

MovRoutine : array[0..3] of TmovProcedure; // lookup table of procedures.

MovRoutine[BitMode]( A, B ); // calls some mov procedure..
AddRoutine[BitMode]( A, B );

This way all the compares and jumps can be avoided and it's replaced with a
table lookup and a single call, and possible some register moves or
whatever.

If the number of bit modes increases this might turn out to be faster ? or
maybe there are other techniques....

I am hoping that if the CPU implement this flexible instruction set encoding
idea, this overhead might be prevented

Thus my and yours flexible computer program parts might execute at pretty
much the same speed without any penalities ! and still being able to update
to future requirements without even having to recompile ! that would be
nice.... just one variable needs to set at runtime which other code can
figure out what to do, for example:

If FileSize(SomeFile) > Max32Bit then
begin
BitMode := 64bit;
end;

Something like that... then file handling or whatever can be flexibly coded.

Other benefits are for the compilers the have a generic or flexible integer
type:

procedure Example:
var
A : TflexibleInteger;
B : TflexibleInteger;
C : TflexibleInteger;
begin
// whatever...
A := B * C;
end;

More suited for flexible math me thinks Programmer doesn't have to mess
around with different data types... just concentrates on the math where
appriorate.

Only one version needed not many ! VERY NICE ! =D

Now I go eat my breakfast !

Bye,
Later,
Skybuck !

 

[Skybuck Flying]

Hello,

Some parts of the computer program could benefit from being flexible for
example:

If the some parts of the computer could turn itself from 32 bit into 64
bit at runtime that could be very handy, then that code does not have to
be re-written or added, it's simply the same code/instructions.

However other parts of the program must remain compatible with todays
designs which could require 8 bit, 16 bit, 32 bit data types and
instructions.

So the idea is to extend the current intel/amd instruction set with a
flexible instruction set encoding it works like this:

The CPU has an extra variable for example called "BitMode".

The BitMode is set to whatever the section of the code needs for example
16 bit, 32 bit, 64 bit.

It might also be pushed onto the stack so that each procedure could
actually have it's own BitMode, so that procedures can even call other
procedures with mixing things up.

I ment without mixing things up, now bitmodes can be mixed in a computer
program, so it can be interpreted both ways

Then the new flexible instruction encoding examine this variable.

The CPU then does the following "underwater":

Let's first give program example:

instruction: SetBitMode, 64
instruction: move register A, register B
instruction: add register A, register B
instruction: compare register A, register B
instruction: jumpifgreater to etc.

Now what the cpu "underwater" does is for each instruction is:

// first move instruction:

if BitMode = 8 then
begin
mov8bit register A8bit, register B8bit
end else
if BitMode = 16 then
begin
mov16bit register A16bit, register B16bit
end else
if BitMode = 32 then
begin
mov32bit register A32bit, register B32bit
end else
if BitMode = 64 then
begin
mov8bit register A64bit, register B64bit
end;

// second add instruction:

if BitMode = 8 then
begin
add8bit register A8bit, register B8bit
end else
if BitMode = 16 then
begin
add16bit register A16bit, register B16bit
end else etc


I just had this idea, I didn't try coding it in Delphi (with operator
overloading or whatever).

But ofcourse I can already see that if I would code this with existing
instruction sets all the if statement could/would (?) Kill performs
somewhat...

I might not even be that bad compared to other solutions... but there is
still some overhead.... Maybe a lookup table and calls might help who
knows ?

For example:

BitMode = 0; // 8 bit
BitMode = 1; // 16 bit
BitMode = 2; // 32 bit
BitMode = 3; // 64 bit;

MovRoutine : array[0..3] of TmovProcedure; // lookup table of procedures.

MovRoutine[BitMode]( A, B ); // calls some mov procedure..
AddRoutine[BitMode]( A, B );

This way all the compares and jumps can be avoided and it's replaced with
a table lookup and a single call, and possible some register moves or
whatever.

If the number of bit modes increases this might turn out to be faster ? or
maybe there are other techniques....

I am hoping that if the CPU implement this flexible instruction set
encoding idea, this overhead might be prevented

Thus my and yours flexible computer program parts might execute at pretty
much the same speed without any penalities ! and still being able to
update to future requirements without even having to recompile ! that
would be nice.... just one variable needs to set at runtime which other
code can figure out what to do, for example:

If FileSize(SomeFile) > Max32Bit then
begin
BitMode := 64bit;
end;

Something like that... then file handling or whatever can be flexibly
coded.

Other benefits are for the compilers the have a generic or flexible
integer type:

procedure Example:
var
A : TflexibleInteger;
B : TflexibleInteger;
C : TflexibleInteger;
begin
// whatever...
A := B * C;
end;

More suited for flexible math me thinks Programmer doesn't have to mess
around with different data types... just concentrates on the math where
appriorate.

Only one version needed not many ! VERY NICE ! =D

Now I go eat my breakfast !

Bye,
Later,
Skybuck !

Bye,
Skybuck.

 

[Skybuck Flying]

procedure Example:

var
A : TflexibleInteger;
B : TflexibleInteger;
C : TflexibleInteger;
begin
// whatever...
A := B * C;
end;

More suited for flexible math me thinks Programmer doesn't have to mess
around with different data types... just concentrates on the math where
appriorate.

Only one version needed not many ! VERY NICE ! =D

Overflows, underflows, range check errors are a concern, so the programmers
should have access to the bitmode as well, ofcourse !

Read/Write.

Example:

if BitMode = 16 then
begin
if B < 10000 then
begin
if C < 10 then
begin
A := B * C;
end;
end;
end else
if BitMode = 32 then
begin
if B < 1000000 then
begin
C < 100 then
begin
A := B * C;
end;
end;
end;

Not so good, maybe this better:

If B < 1000, C < 100 then BitMode := 16;
if B < 100000, C < 1000 then BitMode := 32;
if B < 10000000, C < 100000 then BitMode := 64;

If programmer is scared about overflows, this nasty code might still be
needed.

Alternatively the cpu can set overflow, range check error flags etc.

Then programmer might use those...

For some reason: BitMode := 64;

A := B * C;

if RangeCheckError or OverflowError then
begin
// oopsie.
end;

Even cooler would be if cpu's simply work on arbitrary bit length via memory
operations

Then register only function as pointers, and the program is limited to
hardware memory and addressing, etc.

AddressOutOfRange or so in case still overflow

Bye,
Skybuck.

 

[MooseFET]

Hello,

Some parts of the computer program could benefit from being flexible for
example:

If the some parts of the computer could turn itself from 32 bit into 64 bit
at runtime that could be very handy, then that code does not have to be
re-written or added, it's simply the same code/instructions.

My home computer does this. Right now most of the instructions it is
doing are 64 bit mode.

However other parts of the program must remain compatible with todays
designs which could require 8 bit, 16 bit, 32 bit data types and
instructions.

Take a look at the x86 instruction set. It does this. As horrid and
clunky as it is, it does it.

So the idea is to extend the current intel/amd instruction set with a
flexible instruction set encoding it works like this:

The CPU has an extra variable for example called "BitMode".

The BitMode is set to whatever the section of the code needs for example 16
bit, 32 bit, 64 bit.

Why do this instead of the way it is already done in the x86?


A much better idea would be to make it able to change the sort of CPU
it appears to be. You could then write stuff that does this sort of
thing:


CallAs6502 MyGame
CallAs586 CleanDisk
CallAsZ80 Pong

This can be done by having a loadable control store. The trick would
be loading it quickly enough to not add a bunch of overhead.

 

[Stephen Sprunk]

Some parts of the computer program could benefit from being flexible for
example:

If the some parts of the computer could turn itself from 32 bit into 64
bit at runtime that could be very handy, then that code does not have to
be re-written or added, it's simply the same code/instructions.

However other parts of the program must remain compatible with todays
designs which could require 8 bit, 16 bit, 32 bit data types and
instructions.

So the idea is to extend the current intel/amd instruction set with a
flexible instruction set encoding it works like this:

You missed that boat by about two decades; that's the solution that Intel
used in the 386 to add 32-bit instructions, and the same solution that AMD
used later in K8 to add 64-bit instructions.

S

 

[Skybuck Flying]

My home computer does this. Right now most of the instructions it is
doing are 64 bit mode.

Probably not:

The code behind it was probably re-written, or copy pasted and modified for
64 bit.

So it's not really doing the idea above.

The idea above is: the same code and the same instructions do different
things based on the bitmode "control word" as you called it

Bye,
Skybuck.

 

[Skybuck Flying]

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.

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.

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)

The result:

The user of application is screwed and will have to wait until something is
done about it

(Developers probably screwed as well, multiple versions)

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.

Thanks to these bitmode variables the program can alter it's operation
during runtime.

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.

However now that I think about it... maybe programs could alter themselfes
for the amd case.

For example:

Compilers could "reserve/insert" some unused spaces in the instruction
encodings... and then later fill these with the rex prefixes... in case the
instructions needed to be converted to 64 bit.

I am not sure if these "space inserted instruction encodings" would work on
exisiting 32 bit applications.

Maybe if they were nops or something it might work... or maybe not...

Worth a try

Maybe like:

32 bit application ready for conversion to 64 bit:

Nop
Mov A,B
Nop
ADD A,C
Nop
Jump
Nop
Etc

Then if the program needs to run as 64 bit it converts itself by overwriting
the nops with rex field:

Rex
Mov A,B
Rex
ADD A,C
Rex
Jump
Rex
Etc

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

Bye,
Skybuck.

 

[Jules]

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

I'm not familiar with x86_64, but it seems you're completely
misunderstanding Intel's 16/32 bit switching. Intel introduced a bit
in the segment descriptor of the executable code, equivalent to your
BitMode variable, to specify whether the default code size is 16 bits
or 32 bits. An instruction prefix code (66h) can be used to execute
an instruction using the size that is not the default.

I assume that AMD were smart enough to do something similar.

 

[John Larkin]

Hello,

Some parts of the computer program could benefit from being flexible for
example:

If the some parts of the computer could turn itself from 32 bit into 64 bit
at runtime that could be very handy, then that code does not have to be
re-written or added, it's simply the same code/instructions.

Good grief, mode bits have been around for decades.

John

 

[MitchAlsup]

The x86-64 instruction set already has most of this feature (if you
want to call it that).

x86 has different encoding from 8-bit and for larger bit operations--
almost always just by changing the low order bit of the opcode "byte".
Originally, this was 8-bit versus 16-bits, but later this became 16-
bits or 32-bits by using a operand-size prefix, and finally 16/32/64-
bits. So, the large integer ADD instruction can be preceeded by a
prefix to modulate between 16-bit and 32-bit modes on an instruction
by instruction basis by using the operand-size prefix. Similar
trickery can be performed while computing addresses by using the
address-size prefix. When it comes to 64-bit computations, one can use
either the REX prefix to modulate operand size (and access more
registers) or continue to use the operand size prifix to select
operand sizes (rather) dynamically.

So, basically, there is one opcode (ADD) that can be performed with 16-
bit, 32-bit, or 64-bit operands. Just what the originator desired
(excepting the 8-bit stuff).

Similar trickery goes on in the MMX/SSE instruction set where other
prefixes change from packed integer of various sizes, to packed
floating points of varous sizes.

 

[Skybuck Flying]

I'm not familiar with x86_64, but it seems you're completely
misunderstanding Intel's 16/32 bit switching.
Intel introduced a bit
in the segment descriptor of the executable code, equivalent to your
BitMode variable, to specify whether the default code size is 16 bits
or 32 bits. An instruction prefix code (66h) can be used to execute
an instruction using the size that is not the default.

I assume that AMD were smart enough to do something similar.

I am not interested in 16/32 bit switching but thanks for the explanation
anyway, that's probably how the 32/64 bit switching works.

I have seen these 66h opcodes, the rex opcodes is probably something
similiar or slighty different for extra register addressing.

Maybe you do not understand my concept, my concept is that the BitMode
variable is not encoded into the instruction encoding itself.

It's outside the instructions.

This means the bitmode variable can influence multiple instructions.

For example a whole program could be written this way, and only one bitmode
variable needs to be set/changed in the complete program !

Unless maybe one wants to make sure each routine can have it's own
bitmode... then it's a bitmode per routine on the stack or so.

All the instruction encodings remain the same for such a flexible program.

Bye,
Skybuck.

 

[Spehro Pefhany]

Good grief, mode bits have been around for decades.

John

One math package I wrote for the 8049 could be flipped from 16 bits to
32 bits with a mode bit (I used the precious one in the status
register so it could be read anywhere at minimum cost). It saved a
fair bit of space. Most of the input and output calculations had to be
done to 16 bits resolution, while the internal control and signal
processing needed 32.

Best regards,
Spehro Pefhany

 

[Skybuck Flying]

The whole idea for the variable BitMode is SPEED.

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

Setting a BitMode variable just once SOUNDS FAST =D

That's what I want, during the startup/initialization or whatever the
program figures out what the user wants to do and how many bits are needed
for it and configures the program to run with that many bits.

I want to set those bits once, not every time !

Preferably in a high level language.

The program/I could ofcourse generate all necessary assembler instructions
at runtime/dynamically but that would start to destroy the benefit of a high
level language if I end up having to write it myself... modifieing or adding
REX instructions at runtime might be very tricky too and also possible
destroy the benefits of high level language ! not to ment ruin the speed of
the program and development in general

Bye,
Skybuck.

 

[John Larkin]

One math package I wrote for the 8049 could be flipped from 16 bits to
32 bits with a mode bit (I used the precious one in the status
register so it could be read anywhere at minimum cost). It saved a
fair bit of space. Most of the input and output calculations had to be
done to 16 bits resolution, while the internal control and signal
processing needed 32.

Best regards,
Spehro Pefhany

The LINC-8 had a mode bit, and would execute PDP-8 or LINC programs.
In addition to a totally different instruction set, the PDP-8 was a
2's complement machine, and LINC was sign-magnitude.

The S/360 could run 1401 opcodes! VAX had a PDP-11 mode.

As noted elsewhere, a Pentium can run in 16 or 32-bit mode. The
preamble byte flips the next instruction into the opposite of the
current mode.

Skybuck keeps inventing things that were already invented decades ago,
probably because he does no reading, no research.

John

 

[John Larkin]

The whole idea for the variable BitMode is SPEED.

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

Pentiums have a mode bit. The preamble byte makes the next instruction
execute in the currently-non-selected mode, so it's rarely used. I use
it occasionally to execute 32-bit BIOS calls from PowerBasic, which is
a 16-bit DOS compiler.

Jeez, read up on this stuff. Google "mode bit" or something first
before you announce inventions.

John

 

[Skybuck Flying]

About this bit you mentioned it does not exist in AMD's extended
mumbo-jumbo, they missed it me thinks.

I also wonder if the 16/32 bit you mentioned actually works, I never tried.

Are you saying that if I encode:

mov al, ah

The instruction code can be interpreted as 16 bit by the cpu ?

or maybe:

mov ax, bx

Can this be interpreted as 8 bits ? or 32 bits ?

Never heard of such a thing and I doubt it !

Maybe it works for some things but not everything ??!

Anyway here is what the manual has to say about 64 bit mode:

"
In 64-bit mode, the default address size is 64 bits and the default operand
size is 32 bits. Defaults
can be overridden using prefixes. Address-size and operand-size prefixes
allow mixing of
32/64-bit data and 32/64-bit addresses on an instruction-by-instruction
basis. Table 3-4 shows
valid combinations of the 66H instruction prefix and the REX.W prefix that
may be used to
specify operand-size overrides in 64-bit mode. Note that 16-bit addresses
are not supported in
64-bit mode.
REX prefixes consist of 4-bit fields that form 16 different values. The
W-bit field in the REX
prefixes is referred to as REX.W. If the REX.W field is properly set, the
prefix specifies an
operand size override to 64 bits. Note that software can still use the
operand-size 66H prefix to
toggle to a 16-bit operand size. However, setting REX.W takes precedence
over the operandsize
prefix (66H) when both are used.
In the case of SSE/SSE2/SSE3 SIMD instructions: the 66H, F2H, and F3H
prefixes are mandatory
for opcode extensions. In such a case, there is no interaction between a
valid REX.W prefix
and a 66H opcode extension prefix.
"

Bye,
Skybuck.

 

[Skybuck Flying]

Pentiums have a mode bit. The preamble byte makes the next instruction
execute in the currently-non-selected mode, so it's rarely used. I use
it occasionally to execute 32-bit BIOS calls from PowerBasic, which is
a 16-bit DOS compiler.

What you mean with preamble byte, a prefix ?

That's nothing new... the 64 bit mode has a rex prefix to make the
instructions and operand 64 bit, otherwise default is 32 bits.

There is no way to change the default size... there is no bit concept like
mine.

The 16/32 bit did have a bit mode some claim.... I never tried it.

Will it interpret byte encodins differently ? All ?

I doubt it.

Can I simply write:

mov al, cl
mov ax, cx
mov eax, ecx

and have all these encodings interpreted as 32 bits ? by setting a bit mode
?

I seriously doubt it !

But that's exactly what I want !

I want a generic instruction:

mov A, C

and I want a bit mode that tells the cpu how to interpret it !

And I want it on a instruction "group" or possible routine "basis".

mov A,C
add B,A
etc
just like I wrote...

If you claim the pentium can do this then please provide an example !

Bye,
Skybuck.

 

[Michael A. Terrell]

The LINC-8 had a mode bit, and would execute PDP-8 or LINC programs.
In addition to a totally different instruction set, the PDP-8 was a
2's complement machine, and LINC was sign-magnitude.

The S/360 could run 1401 opcodes! VAX had a PDP-11 mode.

As noted elsewhere, a Pentium can run in 16 or 32-bit mode. The
preamble byte flips the next instruction into the opposite of the
current mode.

Skybuck keeps inventing things that were already invented decades ago,
probably because he does no reading, no research.

John

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

--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

 

[Nobody]

What you mean with preamble byte, a prefix ?

That's nothing new... the 64 bit mode has a rex prefix to make the
instructions and operand 64 bit, otherwise default is 32 bits.

There is no way to change the default size... there is no bit concept like
mine.

Wrong. The default mode is set in the descriptor block for each segment.
The prefix byte doesn't say "use 32-bit mode", it says "use the other
mode". If the segment is set for 16-bit code, the prefix makes an
individual instruction use 32 bits; if it's set for 32 bits, it makes it
use 16 bits.

It's the same thing as your "BitMode", but it isn't enough to just let you
turn 16-bit code into 32-bit code. The problem is that values get stored
in memory, and the amount of memory required depends upon the number of
bits.

If 32-bit code needs to store 2 pointers at successive addresses, those
addresses will be 4 bytes apart, e.g.:

mov [bp-8], si
mov [bp-4], di

In 32-bit mode, the 32-bit versions of si/di (i.e. esi/edi) will be
stored; in 16-bit mode, the 16-bit versions will be stored (similarly, bp
will be the 32-bit ebp in a 32-bit mode). The actual sequence of
opcodes is identical regardless of mode.

In a 16-bit mode, there would be 2 unused bytes between the two values.
But in a 64-bit mode, the stored values would overlap as they are
only 4 bytes apart.

There's no way that the compiler can handle this aspect automatically.
The code would have to be written to avoid fixed offsets altogether in
favour of "base + multiple * word-size" constructs, where word-size is
determined at run-time. This could have a substantial performance penalty:
using compile-time constants is often faster than using run-time variables.

 

[MooseFET]

Probably not:

The code behind it was probably re-written, or copy pasted and modified >for 64 bit.

The code was merely recompiled for 64 bit operations. Not all of it
is 64 bit.

If I click on that
<-----------
button over there, I run SwitcherCad3 as a 32 bit application under
wine.

If I run "octave", it runs as a 64 bitter if I watch a video, it
depends on the type of video whether the thing runs 64 bit or 32 bit.

So it's not really doing the idea above.

The idea above is: the same code and the same instructions do different
things based on the bitmode "control word" as you called it

That already happens on an x86_64