On 2014/03/31 13:32:53, Sven Panne wrote:
Browsing through the simulator code a bit, I think the fundamental
problem is
that passing around the register size at runtime is a bad idea from a
performance point of view. This leads to tons of dynamic checks and the
casting
problem at hand, and we're just trying to cure the symptoms. The "real
cure"
IMHO would be templatizing the size of the register in question, i.e.
make it
a
compile time parameter, not a runtime parameter. With this, the need for
the
funky type puns plus a lot of dynamic checks vanishes. Depending on how
one
does
it, it increases the code size of the simulator, but given how slow it is
currently, this might be a very good trade-off.
I agree that passing register size around is not ideal. But I disagree that
changing that will solve this problem. There is one register file that is
64
bits. This can be accessed by both 32 bit op codes and 64 bit op codes.
The
register access for those 32 bit operations are going to need to read/write
to
the 64 bit register file because it's shared. So there needs to be some
sort of
memcpy/type pun to accomplish this.
Or I remove most of my changes and leave in the register size and mask the
access to the register like Set(int64_t new_value, unsigned size) is doing
now.
That is still going to need some casting to write/read floats and doubles.
I
was trying to avoid branches in the template as I had done in my previous cl
because I thought that was where the compiler was failing.
https://codereview.chromium.org/213943002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
