[libre-riscv-dev] [Bug 278] POWER v3.0B spec ambiguity on EXTS and missing EXTZ

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=278

--- Comment #3 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #2)
> (In reply to Jacob Lifshay from comment #1)
> > You don't need an infinite number of hardware bits to represent the
> > mathematical integer, since you know the exact range the values fall in so
> > you can calculate exactly how many bits you need, sign/zero-extending as
> > needed when converting back to a bitstring.
> 
> if it's ok i'd like to go with "EXTS returns bitsize of 256" and see how
> that goes, because string-to-int comes with a performance penalty.

Basically all that's needed is to create a new type with the original bits and
record if it's sign or zero extended, no Python strings need to be created or
processed. What I called a bitstring above is basically a bitvector and the
same as the underlying bits in a nmigen Signal, I used the name bitstring
instead of nmigen Signal since there are people on the openpower list who
aren't familiar with nmigen.
> 
> yes so do python Longs (to use a python2-ism) however i don't believe it
> will be as high.

nmigen's simulator uses python longs internally to represent the value of a
Signal, so it shouldn't be that much slower.

> keep this bug open so we have an alternative idea.

-- 
You are receiving this mail because:
You are on the CC list for the bug.