I suggest, as mentioned in IRC logs, to make these operate on 1/4 of the register (so XLEN-XLEN/4).

it's not the register itself that's the issue, it's the immediate.
or, when XLEN=8, "[0]*(XLEN-16)" returns a *negative* length for
a list!  -8 zeros?

i've just spotted that xoris, andis and oris will also barf:

    RA <- (RS) ^ ([0]*(XLEN-32) || UI || [0]*16)
    RA <- (RS) & ([0]*(XLEN-32) || UI || [0]*16)

so these need some thought as well.

UI in D-form currently specifies a 16-bit integer. Either it must be re-considered, or we're out of luck. It produces at least 16 bits.

I think the most natural and logical change to fixedlogical (no pun intended) is scaling all things appropriately, i.e.

RA <- (RS) ^ ([0]*32 || UI || [0]*16)

...is converted into this:

RA <- (RS) ^ ([0]*(XLEN/2) || (UI & ([0b1]*(XLEN/4))) || [0]*(XLEN/4))

and this...

if      a <u ([0]*(XLEN-16) || UI) then c <- 0b100
else if a >u ([0]*(XLEN-16) || UI) then c <- 0b010

...is converted in a similar fashion:

if      a <u ([0]*(XLEN-(XLEN/4)) || (UI & ([0b1]*(XLEN/4))) then c <- 0b100
else if a >u ([0]*(XLEN-(XLEN/4)) || (UI & ([0b1]*(XLEN/4))) then c <- 0b010

(In reply to dmitry.selyutin from comment #3)
> UI in D-form currently specifies a 16-bit integer. Either it must be
> re-considered, or we're out of luck. It produces at least 16 bits.

i believe it's reasonable to truncate those to 8 bit for XLEN=8
it does however mean an "if" statement:

if XLEN = 8 then
   # and now for something completely different
   # https://www.youtube.com/watch?v=iTUAhkzVa0M&list=PLnCJp8j83vkH0tD6jOnGc5kPCeiml2tG5

for andi xori etc. these should all be something like:

if XLEN=8 then
    RA <- (RS) ^ UI[8:15]
else
    RA <- (RS) ^ ([0]*(XLEN-16) || UI)

(In reply to Luke Kenneth Casson Leighton from comment #6)
> for andi xori etc. these should all be something like:
> 
> if XLEN=8 then
>     RA <- (RS) ^ UI[8:15]
> else
>     RA <- (RS) ^ ([0]*(XLEN-16) || UI)

i had a bit of a think about this, and feel that this is one
of those exceptional cases where we could justify a function,
to be added to section 1.3.2

the function proposed, in the usual obtuse shortness paradigm,
so loved by spec writers, would be XLT or XTRUNC, and would
be like this:

def XTRUNC(x):
    return SelectableInt(x.value, min(x.bits, XLEN)

where SelectableInt takes care of the required truncation
of the input value.

all locations that risk an overflow when XLEN is less than
the immediate width after zero-extending would be simply:

     RA <- (RS) ^ XTRUNC([0]*(XLEN-16) || UI)

nothing more sophisticated.

this minimises the intrusiveness into the pseudocode, which would
otherwise see significant disruption and lack of clarity.

(In reply to Luke Kenneth Casson Leighton from comment #7)
> (In reply to Luke Kenneth Casson Leighton from comment #6)
> > for andi xori etc. these should all be something like:
> > 
> > if XLEN=8 then
> >     RA <- (RS) ^ UI[8:15]
> > else
> >     RA <- (RS) ^ ([0]*(XLEN-16) || UI)
> 
> i had a bit of a think about this, and feel that this is one
> of those exceptional cases where we could justify a function,
> to be added to section 1.3.2

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

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.

(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.

this one needs careful thought.  i cannot say i am happy with any
options (including the XLTRUNC one), whatever is done
though, we have to have good justification for it.

(In reply to Luke Kenneth Casson Leighton from comment #10)
> this one needs careful thought.  i cannot say i am happy with any
> options (including the XLTRUNC one), whatever is done
> though, we have to have good justification for it.

if we do add a XLTRUNC function, I think it should truncate/zero-extend to XLEN, so XLTRUNC(UI) is valid for XLEN <, =, or > 16. perhaps we should instead call it XLCASTU, and have a corresponding sign-extending/truncating XLCASTS function.

we will also probably want functions for the much-more-complex floating-point XLEN handling

(In reply to Jacob Lifshay from comment #11)
> (In reply to Luke Kenneth Casson Leighton from comment #10)

> if we do add a XLTRUNC function, I think it should truncate/zero-extend to
> XLEN, so XLTRUNC(UI) is valid for XLEN <, =, or > 16. perhaps we should
> instead call it XLCASTU, and have a corresponding sign-extending/truncating
> XLCASTS function.

that makes sense

(In reply to Jacob Lifshay from comment #12)
> we will also probably want functions for the much-more-complex
> floating-point XLEN handling

ah these i was planning to just totally cheat, and override the
function names.  e.g. DOUBLE2SINGLE gets redirected to SINGLE2HALF

have to see when we get to it.

helpers.py:

+    def XLCASTU(self, value):
+        bits = min(value.bits, self.XLEN)
+        return SelectableInt(value.value & ((1 << bits) - 1), self.XLEN)
+

that can just be:

        return SelectableInt(value.value, self.XLEN)

with a comment explaining that SelectableInt performs the required
value truncation.

This one should also be closed, but I think this one deserves a budget allocation. Which task could be used?

It seems we lost one task for budget allocation. Even if budget allocation is impossible now, this should be at least closed. Luke, could you please do this process?