[Libre-soc-bugs] [Bug 684] XLEN-16 fails when XLEN=8

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=684

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #8)

> I disagree... the code could be easily written as:
> RA <- (RS) ^ ([0]*48 || UI)[63-XLEN:63]

if it can be made to work for XLEN=128, great.
and is readable, and is not too intrusive a
change.

remember last week's meeting with Paul, he said we
have to find justifications for these fundamental
ISA RFCs.

otherwise IBM Engineers will see our work as hostile
and a total waste of effort, and reject it as a waste
of time.

i posted about this only a few days ago, did you read the
message?



> and instructions like xoris would be:
> RA <- (RS) ^ ([0]*32 || UI || [0]*16)[63-XLEN:63]
> 
> It would not be useful for XLEN <= 16, but still valid. xori would be used
> instead for XLEN <= 16.

yeh totally get why.


when converted to cope with a future XLEN=128 i am slightly
concerned about readability, and questions we have to answer.

"why are you adding 1 zeros in front?"
"why are you making unnecessary changes?"
"128 bit scalar has never been discussed in the ISA WG"
"who do you think you are, trying to force us to do extra work?"
"are you proposing XLEN=128 RIGHT NOW? if not, why are you bothering
to do a half-hearted job?"

etc etc. these and many other tough questions will come up.

extending the zeros from 48 to 48+64 i am concerned is harder
to justify and harder to read, it is not quite clear why so
many zeros are added then cut off again.

even changing the umber of zeros at all makes it harder to read.

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