Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid

OK, let’s get pedantic then.

The operation that would be needed here without the 63-bit restriction is adding a 65-bit signed (delta) to a 64-bit unsigned (context SID), with the constraint that the result (actual SID) fits into a 64-bit unsigned.  Unless you want to do error checking (which probably is a good idea), this can be done entirely with 64-bit unsigned numbers, simply ignoring the modulo wraparounds.  Error checking then just requires a few magnitude checks, which do require some scribbling on the back of an envelope to get right.  All CPU architectures of the last 40 years (OK, maybe since the iAPX 432, which was 1981) that I know of make it not hard to do these things.  Platforms like the JVM do.

CBOR’s "65-bit signed" (64-bit unsigned + sign bit in mt) integer coverage is indeed surprising initially (it is until you start to embrace bignums).  From the C language, implementers should be used to the fact that as soon as you go to "signed 64-bit" (63-bit unsigned + sign bit expressed as two’s complement), there are all kinds of problems.  Of course, not all C courses teach this…  (The main problem being that 64-bit is big enough that many implementers never reach the boundaries of this space.)

So the problem here really is in the platform or BKAC (between keyboard and chair), not in the architecture...

Grüße, Carsten

> On 2020-01-15, at 17:40, Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
> 
>  
>  
> > -----Original Message-----
> > From: Carsten Bormann <cabo@tzi.org>
> > Sent: 15 January 2020 15:46
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>
> > Cc: Michael Richardson <mcr+ietf@sandelman.ca>; core@ietf.org
> > Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid
> >
> > Yeah, but here the problem is in the head of the implementor and not in
> > the CPU architecture :-)
>  
> I'm not sure that I agree, 😉
>  
> I might be wrong, but most CPU architectures don't support 64 bit negative values (unless you move to 128 bit signed numbers with the corresponding performance overhead).  Of course, implementors can work around the architecture limitations by emulating 64 bit negative numbers using unsigned 64 bit numbers ... 
>  
>  
> In fact, I was wondering whether it is really a good thing that CBOR allows a 64 bit negative integer to be expressed.  It means that the CBOR encoding can easily carry values that most implementations cannot easily generate or represent.
>  
> So, I looked at the first available C implementation example at https://cbor.io/impls.html, and it can't handle negative 64 bit numbers, overflowing them into a long variable.  I wonder what proportion of CBOR implementations do handle these correctly ...  Of course, I'm not suggesting changing the spec, just a retrospective observation.
>  
> > I was not suggesting the text behind the
> > substitutes to be included, this was just explanation why I’d like to have
> > the change.
> [RW] 
> Yes, but I think that "architectures" is probably the correct term here, at least until we end up with CPUs with a 65 bit signed datapath, although I have to confess that I doubt that the choice of word really matters. 😊
>  
> Thanks,
> Rob
>  
>  
>  
> >
> > Grüße, Carsten
> >
> >
> > > On 2020-01-15, at 16:01, Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: core <core-bounces@ietf.org> On Behalf Of Carsten Bormann
> > >> Sent: 15 January 2020 13:35
> > >> To: Michael Richardson <mcr+ietf@sandelman.ca>
> > >> Cc: core@ietf.org
> > >> Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid
> > >>
> > >> (No chair hat.)
> > >>
> > >> On 2020-01-13, at 19:11, Michael Richardson <mcr+ietf@sandelman.ca>
> > wrote:
> > >>>
> > >>> The use of 63-bit unsigned integers allows SIDs to be manipulated
> > >>> more easily  on architectures that might otherwise lack native
> > >>> 64-bit
> > >> unsigned arithmetic.
> > >>> The loss a single bit of precision is not significant given the size
> > >>> of the  space.
> > >>
> > >> s/use of/limitation to/     (we have been using them before)
> > >> s/architectures/platforms/  (Java is our main problem here, no?)
> > > [RW]
> > > I think that it would be awkward for most languages/CPU architectures,
> > anywhere where you could end up with a negative number that is less than
> > 2^63.
> > >
> > > Yes, it is possible to write code in C or Java to handle this, but my
> > > hunch is that implementations could easily get this wrong (e.g. by
> > > just using signed int64 as the type to hold the difference between
> > > parent and child SIDs.)
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > >> s/precision/range/ s/space/remaining space/
> > >>
> > >> Grüße, Carsten
> > >>
> > >> _______________________________________________
> > >> core mailing list
> > >> core@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/core