JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

IRP Specification
Goto page Previous  1, 2, 3, 4
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
3FG
Expert


Joined: 19 May 2009
Posts: 3246

PostPosted: Sun Mar 17, 2013 11:13 am    Post subject: Reply with quote

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:
Note that the "-" prefix is not permitted unless b is present.
So -16::0 is not a legal construct.
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 927

PostPosted: Sun Mar 17, 2013 12:11 pm    Post subject: Reply with quote

3FG wrote:
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.


Quote:
See the end of section 5.3:
Code:
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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3246

PostPosted: Sun Mar 17, 2013 1:04 pm    Post subject: Reply with quote

Yes, I agree: the minus sign in -16::0 is not a prefix.
Back to top
View user's profile Send private message
quietdragon



Joined: 16 Mar 2013
Posts: 8

PostPosted: Sun Mar 17, 2013 3:42 pm    Post subject: Reply with quote

3FG wrote:
See the end of section 5.3:
Code:
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:

<-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:
Quote:
Code:

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).
Back to top
View user's profile Send private message
quietdragon



Joined: 16 Mar 2013
Posts: 8

PostPosted: Sun Mar 17, 2013 3:49 pm    Post subject: Reply with quote

3FG wrote:
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 Wink
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3246

PostPosted: Sun Mar 17, 2013 4:15 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
quietdragon



Joined: 16 Mar 2013
Posts: 8

PostPosted: Mon Mar 18, 2013 9:44 am    Post subject: Reply with quote

3FG wrote:
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:

<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:

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;
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3174
Location: Cambridge, UK

PostPosted: Tue Mar 19, 2013 9:19 am    Post subject: Reply with quote

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 Embarassed .
_________________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4
Page 4 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central