IRP Specification

[3FG]

First, note that the IRP spec has an error: it uses 2's complement rather than 1's complement. However, the accompanying text makes that clear.

See the end of section 5.3:

Code: Select all

Note that the "-" prefix is not permitted unless b is present. 

So -16::0 is not a legal construct.

[Barf]

First, note that the IRP spec has an error: it uses 2's complement rather than 1's complement. However, the accompanying text makes that clear.

I assume you mean to say that whenever the document says "1's complement" the two complement representation of a negative number is meant.

See the end of section 5.3:

Code: Select all

Note that the "-" prefix is not permitted unless b is present. 

So -16::0 is not a legal construct.

Not in my interpretation. In the document, 'the "-" prefix" means the prefix (not the non-positivity of the value) of the width parameter, not a prefix of the value. So X::0 is indeed to be understood as an infinite sequence (beginning with ones if X is negative, zeros if X is positive) (IrpMaster makes it a 63 bit sequence) that can not sensibly be transformed by a bitspec to a finite set of durations, but (only) to an integer expression (that will be finite). This is one flaw of the IRP spec.

[3FG]

Yes, I agree: the minus sign in -16::0 is not a prefix.

[quietdragon]

See the end of section 5.3:

Code: Select all

Note that the "-" prefix is not permitted unless b is present. 

So -16::0 is not a legal construct.

As you can probably tell, I'm a newbie at IRP. Please excuse my questions that miss the mark. What I had meant to write was:

Code: Select all

<-1,1|1,-1>((-16)::0)

I think this is valid syntax.

What is the expected outcome ? I think you're telling me that, without the 2nd (b) parameter, a negative value of the 1st (a) parameter is an error.

Incidentally, when I read section 5.3, I interpreted the section as a whole:

Code: Select all

bitfield = ["~"], primary item, ":", (["-"], primary item, [":", primary item] | ":", primary item);

... Note that the "-" prefix is not permitted unless b is present.

I think the "-" prefix that is mentioned refers to the ["-"] that optionally prefixes the 2nd primary item (ie the b parameter).

[quietdragon]

First, note that the IRP spec has an error: it uses 2's complement rather than 1's complement. However, the accompanying text makes that clear.

ROTFL Well, I had a set of follow up questions about that which are now unnecessary.

Certainly 1s complement has made for a much more interesting implementation

[3FG]

I wrote "So -16::0 is not a legal construct.", and Barf replied correctly that the reasoning I offered for this (negative prefix not allowed if B is empty) doesn't apply.

So my earlier post is wrong, and you should pay attention to what Barf wrote. From my (revised) point of view -16::0 is valid syntax, but it does not have a usefully defined value. In principle it represents an infinite sequence of bits. Barf has chosen to limit the sequence to length 63 in his parser, and that makes the syntax representable in a useful way.

[quietdragon]

So my earlier post is wrong, and you should pay attention to what Barf wrote. From my (revised) point of view -16::0 is valid syntax, but it does not have a usefully defined value.

Ok. Thanks. It would be good to have the specification speak to this case. It could say that implementation behaviour is undefined, or perhaps say that this case should elicit an error.

Another question to clarify my understanding of the interpretation of bitspecs.

Would you confirm my interpretation of the following ?

Code: Select all

<0:3|1:3|2:3|3:3|4:3|5:3|6:3|7:3>( <0:2|1:2|2:2|3:2|>(A:2) ^P <0:1|1:1>(B:1) )

My reading of the specification says that interpretation of sub-bitspec A (and subsequently sub-bitspec B also) is that it must translated in the context of bitspec <0|1|2|3|>, and then recursively in the context of the outer global bitspec <0|1|2|3|4|5|6|7>.

In this case, sub-bitspec A only contributes two bits, so there are insufficient bits when processing the outer global bitspec, and an error is issued.

I think the motivation for interpreting the semantics in this way is to allow the extent ^P to have a useful meaning: that the duration of the extent refers to the actual final IR signal. Without recursively processing the sub-bitspec all the way to the global outer bitspec, the duration extent can only refer to an intermediate signal whose timing will likely differ from the final IR signal.

I think this interpretation is described in the Execution Model:

Code: Select all

PROCESS buffer
BEGIN

    (* This buffer is in scope of previous bitspec, if any *) 
    ...
        (* The current bitspec now was the previous bitspec on entry *) 
        IF current bitspec IS NOT NULL THEN

            (* if an attempt has been made to push bits into its buffer, it will already have generated an error *) 
            PROCESS buffer OF current bitspec; 

        END IF; 

[mathdon]

I am no longer maintaining this IRP Specification document, so to make it easier for others to develop it further, I have posted it also as a MS Word .doc file. I apologise for my confusion between 1's complement and 2's complement as the document uses the wrong one throughout .