More Re: its in the 3s.....

[Ken Hancock]

--- In ExtractStream@y..., Dale Reed <daler@n...> wrote:
> joe666boxer@y... wrote:
> 
> > > From Tyconvert:
> > >
> > > unsigned long size = (((p[0]<<8) | p[1])<<4) | (p[2]>>4);
> > >
> > > From SplitStream:
> > >
> > > TyStream[i].size =
> > > (((unsigned int) buf[header_pos]) << 12) |
> > > (((unsigned int) buf[header_pos + 1]) << 4) |
> > > (((unsigned int) buf[header_pos + 2]) >> 4);
> > >
> > > Anyone notice the subtle difference between the two? It would only
> > > matter if the first byte was non-zero. Wonder which is correct? :)
> > 
> > That looks like a typo in tyconvert. the shifted bits from p[1] will 
> > overwrite the lower 4 bits of p[0], which can't be right. From 
> > Extractstream 0.3 (around line 169):
> > 
> > size = ((*p)[0]<<12 | (*p)[1])<<4 | ((*p)[2]>>4);
> 
> 
> But is it really not a typo in ES? I'm a little rusty on bitwise shifting,
> but this is what I come up with (a=0, b=1, c=2). Now lets also remember 
that
> ES runs on the tivo and tyc runs on my intel box. Would the little endian vs.
> big endian processors be an issue? I'm using sendstream to pull the 
tystream
> off the tivo and then processing them on my Wintel box.
> 
> aaaaaaaa000000000000 << 12
> bbbbbbbb0000 << 4
> cccc >> 4
> 
> aaaaaaaa0000000000000000 << 12 << 4 = 16
> bbbbbbbb0000 << 4
> cccc >> 4
> 
> My problem is when I use the ES method, I get too large of numbers
> that cause overflows. Any thoughts?

I'm not rusty on bit shifting -- I do it every day. Tyconvert uses << 8 on p[0] 
then << 4 on BOTH p[0] and p[1] which is equivalent to << 12 on p[0]. Both 
ES and TyConvert are the same -- people just misread the parentheses.

It's either a matter of programming style or the author thought that his 
version was an optimization by doing the shift as a multiple of 8. On the PPC, 
however, I believe any shift operation of any size is the same number of clock 
cycles, so it doesn't matter -- you still have 2 OR and 3 SHIFT instructions.