> "Orton, Yves" wrote:
>
> > by 'not working' i mean i get undefined sub-rules and
> > such as if i was getting file/stream type redirection
> > instead of the shifts i want.
> > as a result, i've ended up with exe blocks that look like:
> >
> > {
> > $main::Instruction_upper = 0x440000
> > | ($item[1] / 2048)
> > | $item[4]
> > | ($item[8] / 512)
> > | ($item[10] * 16)
> > | (($item[26] & 0x000010) / 16)
> > | ($item[32] / 2)
> > ;
> > $main::Instruction_lower = 0x000000
> > | ($item[14] * 2)
> > | ($item[16] / 2048)
> > | ($item[20] * 16)
> > | ($item[22] / 128)
> > | (($item[26] & 0x00000C) * 1048576)
> > | (($item[28] & 0xC00000) / 16384)
> > | (($item[28] & 0x000003) * 1024)
> > | (($item[34] & 0xC00000) / 1024)
> > | (($item[34] & 0x000003) * 16384)
> > ;
> > 1
> > }
> >
> > it does what's desired, but from a maintenance point of view
> > it is just not clear, without doing some math, what the
> > various shifts are.
> > not to mention the increased chances of a typo in these magic
> > numbers!
> >
> > any ideas about where i've gone wrong in trying to use the
> > bit shifts?
> > or is this a bug in p::rd ?
>
> Dunno about the cause of this. But the obvious solution is to put
> stuff like this in a sub that you call. Frankly I would do that
> anyway. I find large chunks of code intermingled with the grammer is
> difficult to grok. And by using
>
> $item{$name}
> instead of
> $item[$num]
> your code would be much more resiliant to future changes, especially
> if you do move stuff into subs.
>
> Cheers,
> yves
yes, point taken: i've not been happy with the absolute position
information, but i was more focussed on getting something/anything
up quickly and it flowed right from the p::rd stuff i read.
the instruction bit packing is ugly -- at least it happens only at
the point where an instruction has been fully parsed.
i'm a c-hack in perl newbie's clothing....thank you for the ideas, i'll
study them.
hwn
