On 7/25/2012 10:19 AM, Walter Bright wrote:
Is it possible you could code it up and test it using inline asm?
I dummied up some code to do it:
int test(int i)
{
switch (i)
{
case 3: i += 3; break;
case 4: i += 4; break;
case 5: i += 5; break;
case 6: i
On 7/25/2012 11:24 PM, Walter Bright wrote:
jmp near ptr L39
jmp near ptr L3F
jmp near ptr L45
jmp near ptr L4B
jmp near ptr L51
jmp near ptr L57
I tried replacing
On 26/07/12 00:46, Walter Bright wrote:
On 7/25/2012 2:55 PM, Dmitry Olshansky wrote:
std\regex.d(5118): Error: undefined identifier 'L_jumptable'
I was afraid of that. You may have to approximate it by loading the
address of L_jumptable into a register and adding it in instead of
using
the
On 26-Jul-12 10:24, Walter Bright wrote:
On 7/25/2012 10:19 AM, Walter Bright wrote:
Is it possible you could code it up and test it using inline asm?
I dummied up some code to do it:
int test(int i)
{
switch (i)
{
case 3: i += 3; break;
case 4: i += 4; break;
On 26-Jul-12 11:56, Don Clugston wrote:
But doing that screws up the CPUs stack prediction so badly that it
will dominate the timing
At least do something like:
jump_table:
move EAX, [ESP]
ret
BTW this seems to be a roundabout way to get address of label
that I can use do a
On 7/26/2012 1:14 PM, Dmitry Olshansky wrote:
Obviously it's backwards and awful. Makes me wonder why can't we take it
directly, what's limitation ?
How about allowing it, at least in inline assembly?
It can be done, it's just that nobody has done the implementation in the inline
assembler.
On 7/26/2012 8:55 AM, Dmitry Olshansky wrote:
int test(int i)
{
switch (i)
{
case 3: i += 3; break;
case 4: i += 4; break;
case 5: i += 5; break;
case 6: i += 6; break;
case 7: i += 7; break;
case 8: i += 8; break;
default:
On 27-Jul-12 00:31, Walter Bright wrote:
On 7/26/2012 1:14 PM, Dmitry Olshansky wrote:
Obviously it's backwards and awful. Makes me wonder why can't we take it
directly, what's limitation ?
How about allowing it, at least in inline assembly?
It can be done, it's just that nobody has done the
On 27-Jul-12 00:38, Walter Bright wrote:
On 7/26/2012 8:55 AM, Dmitry Olshansky wrote:
int test(int i)
{
switch (i)
{
case 3: i += 3; break;
case 4: i += 4; break;
case 5: i += 5; break;
case 6: i += 6; break;
case 7: i += 7; break;
On 27-Jul-12 00:50, Dmitry Olshansky wrote:
On 27-Jul-12 00:31, Walter Bright wrote:
On 7/26/2012 1:14 PM, Dmitry Olshansky wrote:
Obviously it's backwards and awful. Makes me wonder why can't we take it
directly, what's limitation ?
How about allowing it, at least in inline assembly?
It can
On 7/26/2012 2:17 PM, Dmitry Olshansky wrote:
Filed: http://d.puremagic.com/issues/show_bug.cgi?id=8448
Thank you.
On 7/24/2012 10:04 PM, Dmitry Olshansky wrote:
On 25-Jul-12 03:31, Walter Bright wrote:
On 7/24/2012 3:33 PM, Dmitry Olshansky wrote:
There is no code just jump [ecx]. The offset is included already.
I'm not seeing where code is in the asm code you presented.
Sorry, I have no idea why it
On 25-Jul-12 10:11, Walter Bright wrote:
On 7/24/2012 10:04 PM, Dmitry Olshansky wrote:
BTW Static array for jump table is all
good and well but does this trick work with PIC code?
The jump table can be in the code segment, which is not possible for a
user generated array.
OK, so it works -
On 7/24/2012 11:46 PM, Dmitry Olshansky wrote:
It's pc = address because one can first preprocess all of byte code doing
opcode = address rewrites. But you can't do it unless taking address of labels
is possible.
All right, that's the piece that was missing.
I suppose it is possible for the
On 25-Jul-12 11:37, Walter Bright wrote:
On 7/24/2012 11:46 PM, Dmitry Olshansky wrote:
It's pc = address because one can first preprocess all of byte code
doing
opcode = address rewrites. But you can't do it unless taking address
of labels
is possible.
All right, that's the piece that was
On 25/07/12 09:37, Walter Bright wrote:
On 7/24/2012 11:46 PM, Dmitry Olshansky wrote:
It's pc = address because one can first preprocess all of byte code
doing
opcode = address rewrites. But you can't do it unless taking address
of labels
is possible.
All right, that's the piece that was
On 25-Jul-12 11:51, Don Clugston wrote:
On 25/07/12 09:37, Walter Bright wrote:
On 7/24/2012 11:46 PM, Dmitry Olshansky wrote:
It's pc = address because one can first preprocess all of byte code
doing
opcode = address rewrites. But you can't do it unless taking address
of labels
is possible.
On 25/07/12 09:55, Dmitry Olshansky wrote:
On 25-Jul-12 11:51, Don Clugston wrote:
On 25/07/12 09:37, Walter Bright wrote:
On 7/24/2012 11:46 PM, Dmitry Olshansky wrote:
It's pc = address because one can first preprocess all of byte code
doing
opcode = address rewrites. But you can't do it
On 7/25/2012 12:51 AM, Don Clugston wrote:
so that there is no lookup table, just a multiply.
Rethinking your idea a bit...
Suppose the switch jump_address[] array was really an array of hardcoded jmp
instructions, 5 bytes each:
jmp_table:
jmp Lcase1;
jmp Lcase2;
jmp Lcase3;
On 25/07/12 12:11, Walter Bright wrote:
On 7/25/2012 12:51 AM, Don Clugston wrote:
so that there is no lookup table, just a multiply.
Rethinking your idea a bit...
Suppose the switch jump_address[] array was really an array of hardcoded
jmp instructions, 5 bytes each:
jmp_table:
jmp
On 25-Jul-12 15:14, Don Clugston wrote:
On 25/07/12 12:11, Walter Bright wrote:
On 7/25/2012 12:51 AM, Don Clugston wrote:
so that there is no lookup table, just a multiply.
Rethinking your idea a bit...
Suppose the switch jump_address[] array was really an array of hardcoded
jmp
OK I've taken your comments into account.
Now I think I finally got it right:
mov ecx, [ebx] ; ecx = code[pc]
inc ebx ; pc ++
jmp ecx ; goto code[pc], as ecx is already a pointer
Nope, ecx is an opcode, not a pointer. You need another
indirection.
Man this has been frustrating to read. I
On 7/25/2012 4:26 AM, Dmitry Olshansky wrote:
On 25-Jul-12 15:14, Don Clugston wrote:
On 25/07/12 12:11, Walter Bright wrote:
On 7/25/2012 12:51 AM, Don Clugston wrote:
so that there is no lookup table, just a multiply.
Rethinking your idea a bit...
Suppose the switch jump_address[] array
On 25-Jul-12 21:19, Walter Bright wrote:
On 7/25/2012 4:26 AM, Dmitry Olshansky wrote:
On 25-Jul-12 15:14, Don Clugston wrote:
On 25/07/12 12:11, Walter Bright wrote:
On 7/25/2012 12:51 AM, Don Clugston wrote:
so that there is no lookup table, just a multiply.
Rethinking your idea a bit...
On 7/25/2012 10:29 AM, Dmitry Olshansky wrote:
Is it possible you could code it up and test it using inline asm?
Mm... I could try. So the trick is to add say this:
Dispatch:
asm{
...
lea EAX,jmp_table[EBX][EBX*4]
jmp EAX
jmp_table:
jmp Lcase1;
jmp Lcase2;
On 25-Jul-12 21:47, Walter Bright wrote:
On 7/25/2012 10:29 AM, Dmitry Olshansky wrote:
Is it possible you could code it up and test it using inline asm?
...
Any tips on which spare registers to use (I guess ecx is no go, as
there is
'this' pointer present) ?
I wouldn't worry about it.
On 7/25/2012 12:52 PM, Dmitry Olshansky wrote:
On 25-Jul-12 21:47, Walter Bright wrote:
On 7/25/2012 10:29 AM, Dmitry Olshansky wrote:
Is it possible you could code it up and test it using inline asm?
...
Any tips on which spare registers to use (I guess ecx is no go, as
there is
'this'
On 25-Jul-12 23:58, Walter Bright wrote:
On 7/25/2012 12:52 PM, Dmitry Olshansky wrote:
On 25-Jul-12 21:47, Walter Bright wrote:
On 7/25/2012 10:29 AM, Dmitry Olshansky wrote:
Is it possible you could code it up and test it using inline asm?
...
Any tips on which spare registers to use (I
On 26-Jul-12 00:06, Dmitry Olshansky wrote:
On 25-Jul-12 23:58, Walter Bright wrote:
On 7/25/2012 12:52 PM, Dmitry Olshansky wrote:
On 25-Jul-12 21:47, Walter Bright wrote:
On 7/25/2012 10:29 AM, Dmitry Olshansky wrote:
Is it possible you could code it up and test it using inline asm?
...
On 07/25/2012 01:06 PM, Dmitry Olshansky wrote:
On 25-Jul-12 23:58, Walter Bright wrote:
I was afraid of that. You may have to approximate it by loading the
address of L_jumptable into a register and adding it in instead of using
the addressing mode.
like this ?
mov EDX, L_jumpable
I hope
std\regex.d(5118): Error: undefined identifier 'L_jumptable'
I was afraid of that. You may have to approximate it by loading the
address of L_jumptable into a register and adding it in instead of using
the addressing mode.
I failed to load it in any register or interact with it in any way.
I
On 7/25/2012 2:55 PM, Dmitry Olshansky wrote:
std\regex.d(5118): Error: undefined identifier 'L_jumptable'
I was afraid of that. You may have to approximate it by loading the
address of L_jumptable into a register and adding it in instead of using
the addressing mode.
I failed to load it in
On 24-Jul-12 02:06, Walter Bright wrote:
On 7/23/2012 2:25 PM, bearophile wrote:
Walter Bright:
D already has it: http://dlang.org/statement.html#FinalSwitchStatement
Do you have a proof? (Show me asm code)
Since the final switch does not allow a 'default' case, the check can be
omitted,
On 7/24/2012 12:58 AM, Dmitry Olshansky wrote:
Now if I use final switches there is still:
A) jump table per switch, or maybe less but there is no guarantees
(= depend on another optimization that's not here)
B) it's an ugly and a roundabout way to do this
However I think that always
Le 23/07/2012 18:56, bearophile a écrit :
deadalnix:
The presented example is insanely unsafe. By giving invalid input, you
can basically branch randomly.
The check added by the switch is what is required to make it safe, so
it isn't faster at the end.
The case in the article isn't very
On 24-Jul-12 14:04, Walter Bright wrote:
On 7/24/2012 12:58 AM, Dmitry Olshansky wrote:
Now if I use final switches there is still:
A) jump table per switch, or maybe less but there is no guarantees
(= depend on another optimization that's not here)
B) it's an ugly and a roundabout way to do
On 7/24/2012 6:58 AM, Dmitry Olshansky wrote:
void op_1()
{
...//some code for instruction 1
opcode = cast(function void ())code[pc++];
goto opcode(); //opcode is pointer to function op_xx
}
//can do without goto fn() iff tail call is GUARANTEED
I believe you can do this with:
On 24-Jul-12 21:03, Walter Bright wrote:
On 7/24/2012 6:58 AM, Dmitry Olshansky wrote:
void op_1()
{
...//some code for instruction 1
opcode = cast(function void ())code[pc++];
goto opcode(); //opcode is pointer to function op_xx
}
//can do without goto fn() iff tail call is
On 7/24/2012 12:50 PM, Dmitry Olshansky wrote:
are the same (same as in same number of indirections).
switch (code[pc++])
and
goto code[pc++]()
are the same, too.
It's not. Let's get to assembly then. It's an illustration as I'm no expert and
may have made some illegal shortcuts
On 25-Jul-12 01:40, Walter Bright wrote:
On 7/24/2012 12:50 PM, Dmitry Olshansky wrote:
are the same (same as in same number of indirections).
switch (code[pc++])
and
goto code[pc++]()
are the same, too.
It's not. Let's get to assembly then. It's an illustration as I'm no
expert
On 7/24/2012 3:33 PM, Dmitry Olshansky wrote:
On 25-Jul-12 01:40, Walter Bright wrote:
On 7/24/2012 12:50 PM, Dmitry Olshansky wrote:
are the same (same as in same number of indirections).
switch (code[pc++])
and
goto code[pc++]()
are the same, too.
It's not. Let's get to
On 25-Jul-12 03:31, Walter Bright wrote:
On 7/24/2012 3:33 PM, Dmitry Olshansky wrote:
There is no code just jump [ecx]. The offset is included already.
I'm not seeing where code is in the asm code you presented.
Sorry, I have no idea why it is not the same. jumptable is a static
array,
On 23-07-2012 05:05, deadalnix wrote:
On 23/07/2012 01:35, bearophile wrote:
A discussion appeared few days ago on Reddit, about computed gotos:
http://www.reddit.com/r/programming/comments/wld04/eli_benderskys_website_computed_goto_for/
http://eli.thegreenplace.net/2012/07/12/computed-goto
On Sunday, 22 July 2012 at 23:35:34 UTC, bearophile wrote:
A discussion appeared few days ago on Reddit, about computed
gotos:
For another use case: dotat.at/tmp/gll.pdf
deadalnix:
The presented example is insanely unsafe. By giving invalid
input, you can basically branch randomly.
The check added by the switch is what is required to make it
safe, so it isn't faster at the end.
The case in the article isn't very strong.
Thank you for your answer. We have
On 7/22/2012 4:35 PM, bearophile wrote:
Computed gotos are useful to write interpreters. Interpreters are a niche but
important purpose of system languages like D. Computed gotos are also useful to
implement certain finite state machines (like some used in computational
biology).
D already
Walter Bright:
D already has it:
http://dlang.org/statement.html#FinalSwitchStatement
Do you have a proof? (Show me asm code)
Bye,
bearophile
Do you have a proof? (Show me asm code)
Just to be more clear, what I mean is that given a D program
equivalent to the C code shown in the article:
int interp_cgoto(unsigned char* code, int initval) {
static const void* dispatch_table[] = {
do_halt, do_inc, do_dec, do_mul2,
On 7/23/2012 2:25 PM, bearophile wrote:
Walter Bright:
D already has it: http://dlang.org/statement.html#FinalSwitchStatement
Do you have a proof? (Show me asm code)
Since the final switch does not allow a 'default' case, the check can be
omitted, and the generated code is a simple
Walter Bright:
dmd currently doesn't do that, but that's not the language's
fault, it's a quality of implementation issue.
I understand the difference between what compilers are able to do
(today or in future), and what the language specs allow compiler
writers to do. So in theory I agree.
On 7/23/2012 3:23 PM, bearophile wrote:
This fallacy implies that if you want to actually see a compiler able to perform
a certain optimization, such optimization must be rather easy, this means it
must be easy for the compiler to infer as true all the conditions necessary to
apply that
Walter Bright:
Of course. There's no magic technology there.
Thank you for your answers Walter :-)
Bye,
bearophile
On 7/23/2012 5:05 PM, bearophile wrote:
Walter Bright:
Of course. There's no magic technology there.
Thank you for your answers Walter :-)
You're welcome.
A discussion appeared few days ago on Reddit, about computed
gotos:
http://www.reddit.com/r/programming/comments/wld04/eli_benderskys_website_computed_goto_for/
http://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables/
Computed gotos are useful to write interpreters
On 23/07/2012 01:35, bearophile wrote:
A discussion appeared few days ago on Reddit, about computed gotos:
http://www.reddit.com/r/programming/comments/wld04/eli_benderskys_website_computed_goto_for/
http://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables
On 23-Jul-12 07:05, deadalnix wrote:
On 23/07/2012 01:35, bearophile wrote:
A discussion appeared few days ago on Reddit, about computed gotos:
http://www.reddit.com/r/programming/comments/wld04/eli_benderskys_website_computed_goto_for/
http://eli.thegreenplace.net/2012/07/12/computed-goto
56 matches
Mail list logo
