Hi Konstantin et al, On Fri, 23 Mar 2001 09:35:05 -0500 Konstantin Olchanski <olchansk@ux1.phy.bnl.gov> wrote concerning ": Re: Proposal for T4-T5 unpacking format": > On Fri, Mar 23, 2001 at 01:27:38PM +0100, Christian Holm Christensen wrote: > > On Thu, 22 Mar 2001 22:47:39 -0500 > > Konstantin Olchanski <olchansk@ux1.phy.bnl.gov> wrote > > concerning ": Proposal for T4-T5 unpacking format": > > > > > > prompt wires 1 through 99 are defined as channel numbers 1 through > > > 99 (same as T3). delayed wires 1 through 99 are defined as channel > > > numbers 101 through 199. > > > > Since the TDC records are 8 bit objects, why not split it into two 4 > > bit "psuedo-object", so that prompt channel numbers are in the lower 4 > > bits, and delayed channel numbers are in the upper 4 bits. > > > > I.e., channel 4 is "wire 5, prompt" and channel 149 means "wire 22, > > delayed". > > > > > 1) is there a mistake in the example? wire 22 cannot be encoded > into 4 bits (0..15), even by shifting. Whoops, my mistake - didn't think too much there. > 2) I guess you meant "mark delayed channels by setting bit 128". That would be bit 8 right. Bit 128 would reguire a 16 byte word (that's long long - right?). > This > is a valid optimization, it replaces a modulus 100 operation > with a cheaper bit mask operation. Also: > - it obfuscates the raw data: > the definition "channel 103 is wire 3, delayed" is less obscure > that "channel 132 is wire 3, delayed". Not if you say: "The lower 7 bits sets the wire number, and if bit 8 is set, the wire is delayed." - just like 8 bit character encoding needed to implement an alphabet for any civilised language; like Russian and Danish :-) > - it is an unnecessary optimization, because surely, the event > processing time is dominated by tracking, not by reading T3-T5 raw data, > so speeding up raw data unpacking would have no effect on total > processing time. I was more curious why you didn't choose such a scheme. After all, you are a CS PhD, so I thought you'd think more in terms of bit manipulations, then say the average Physichs PhD would, who's like to make scheme that say "Event numbers are delayed, odd are prompt", or "count delayed from 255 and down and prompt from 0 and up", or something similar :-( > 0) the channels numbers are defined as "wire numbers" and > there is no "wire zero". Wire numbers are counted starting from one, > in every experiment that was ever done. (Counter examples?). ^ | +- :-) That's probably because the DAQ for the old DCs was written in Fortran (4 if they were lucky!), and not the yougster C or even the infant Java! > P.S. The example in (2) has a mistake: 128+3 = 131, not 132. Did you spot it? 10000000 = 2^7 = 128 00000011 = 2^1 + 2^0 = 2 + 1 = 3 10000011 = 2^7 + 2^1 + 2^0 = 128 + 2 + 1 = 131 Ofcourse I did! > P.P.S. I strongly suspect that on modern CPUs the "modulo 100" operation > takes one clock cycle to execute, same is bit masks and shifts. I will > check and report on this. On MIPS R3000/R4000 CPUs it used to > be ~100 clocks (integer division) versus 1 clock (bit ops). Sure. Again, I was more curious as to how you came up with the encoding you did, rather then some bit based one. Also, I know how frustating it is to not get reponse to a proposal, say _something_ :-) Yours, Christian ----------------------------------------------------------- Holm Christensen Phone: (+45) 35 35 96 91 Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 DK-2200 Copenhagen N Web: www.nbi.dk/~cholm Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Fri Mar 23 2001 - 10:04:02 EST