Home > Archive > ASM370 > March 2006 > PACK with explicit zero length for second operand
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
PACK with explicit zero length for second operand
|
|
| Kelly Bert Manning 2006-03-21, 9:57 pm |
| does that end up unpacking a single byte at the specified displacement?
(padded with zeros to fill out the length specified for the right operand)
CH R14,=H'2' TOO MANY CHARS?
BL PARM5D NO, IT'S OKAY
LA R14,2 YES, SET R14 TO 2
SPACE 1
PARM5D DS 0H
BCTR R14,0 R14 = HEX LTH
EX R14,PARM5EX PACK WAIT TIME
CVB R15,DWORD R15 = SECONDS TO WAIT
MH R15,MULTSEC CONVERT TO TIMER UNITS
ST R15,WAITTIME SAVE IT FOR STIMER
B NEXTPARM GO CHECK FOR ANOTHER PARM
SPACE 1
PARM5EX PACK DWORD+6(2),0(0,R15) USE 1ST 2 BYTES ONLY
SPACE 1
R14 gets ORed with DWORD=6(2) doesn't it?
I parse the second operand as an explicit length of zero, giving an
effective length of 1 byte for the source, 1 character digit.
If R14 has a value of 2 wouldn't the effective length of the target field
be 3 bytes, or 5 packed decimal digits and a packed sign? The source digit
and sign would end up 1 byte beyond the end of DWORD.
| |
| John Small 2006-03-22, 7:58 am |
| On Wed, 22 Mar 2006 03:40:58 UTC, bo774@FreeNet.Carleton.CA (Kelly
Bert Manning) wrote:
> does that end up unpacking a single byte at the specified displacement?
> PARM5D DS 0H
> BCTR R14,0 R14 = HEX LTH
> EX R14,PARM5EX PACK WAIT TIME
[snip]
> B NEXTPARM GO CHECK FOR ANOTHER PARM
> SPACE 1
> PARM5EX PACK DWORD+6(2),0(0,R15) USE 1ST 2 BYTES ONLY
> SPACE 1
>
>
> R14 gets ORed with DWORD=6(2) doesn't it?
R14 gets ORed with the second byte of the assembled PACK instruction.
As assembled this 2nd byte would be X'10', the first nibble being the
"length - 1" of the target and the second nibble the "length - 1" of
the source.
If R14 has a value of 2 then the effective length of the source is 3
and the ORed second byte is X'12'. And 3 characters will fit exactly
into 2-byte packed field.
--
John Small
(remove the z's for email address)
| |
| glen herrmannsfeldt 2006-03-22, 7:58 am |
| John Small wrote:
> On Wed, 22 Mar 2006 03:40:58 UTC, bo774@FreeNet.Carleton.CA (Kelly
> Bert Manning) wrote:
(snip)
[color=darkred]
[color=darkred]
> R14 gets ORed with the second byte of the assembled PACK instruction.
> As assembled this 2nd byte would be X'10', the first nibble being the
> "length - 1" of the target and the second nibble the "length - 1" of
> the source.
> If R14 has a value of 2 then the effective length of the source is 3
> and the ORed second byte is X'12'. And 3 characters will fit exactly
> into 2-byte packed field.
But there is BCTR so R14 should be 1 when it gets to the EX.
The assembler assembles one less than the length specified, unless it
is zero in which case it assembles zero. BCTR is often used to subtract
one from a length before an EX, though it doesn't help much for the
high nybble length.
-- glen
| |
| John Small 2006-03-23, 7:57 am |
| On Wed, 22 Mar 2006 12:35:47 UTC, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
> John Small wrote:
>
> (snip)
>
>
>
>
> But there is BCTR so R14 should be 1 when it gets to the EX.
>
You are right about R14 not being 2.
I was responding to the OP's text "If R14 has a value of 2 wouldn't
the effective length of the target field be 3 bytes..." and not
looking at the code.
The OP's problem seemed to be that he thought that R14, as used in
this code, would determine the run-time target length and possibly
overrunning the DWORD field. And my response was an attempt to say
that R14, as used in this code, is intended to affect the run-time
source length.
Upon further thought, the code snippet in the original post does not
ensure that R14 is positive. If R14 is negative or zero upon entry to
the code snippet then it could affect both of the run-time lengths,
depending on the low-order byte of R14 after the BCTR. So a
non-positive value in R14 could cause overruns in the DWORD field.
For example, a value of 0 in R14 upon entry to the code snippet...
- would be changed to -1 by the BCTR
- the -1 in R14 would cause the EX'd PACK instruction (after the
run-time OR of the 2nd byte of the PACK instruction) to be the
equivalent of:
PACK DWORD+6(16),0(16,R15)
So if the OP was trying to find a bug in this code that was causing
overruns, then the bug may be that this code does not ensure that R14
has a valid length (1-16 on entry, 0-15 after the BCTR) for a source
field.
--
John Small
(remove the z's for email address)
| |
| Kelly Bert Manning 2006-03-23, 6:57 pm |
| "John Small" (zjsmallz@toast.net) writes:
>
> So if the OP was trying to find a bug in this code that was causing
> overruns, then the bug may be that this code does not ensure that R14
> has a valid length (1-16 on entry, 0-15 after the BCTR) for a source
> field.
Actually, the odd behaviour is that it wasn't looping when passed a c'03'
value, but I appreciate the discussion and explanations. The explanation
for that must lie somewhere else.
I'll add comments explain this to the code to assist anyone else who has
to try and parse it over the next few years.
The fellow who originally coded this retired years ago. While we can't find
him I do hope that he is enjoying doing "whatever I want, whenever I want",
which was his response when someone asked him what he planned to do at his
retirement send off.
| |
| John Small 2006-03-24, 7:56 am |
| On Thu, 23 Mar 2006 15:10:47 UTC, bo774@FreeNet.Carleton.CA (Kelly
Bert Manning) wrote:
> "John Small" (zjsmallz@toast.net) writes:
>
> Actually, the odd behaviour is that it wasn't looping...
What loop? I don't see one in the code.
> when passed a c'03' value, ...
?? The only data used by this code segment are:
R14 : presumably the length of the character data to be PACK'ed
R15 : presumably the address of the character data to be PACK'ed
MULTSEC : presumably a Halfword containing a conversion factor of
some kind.
=H'2' : a Halfword value of 2 (unless it has been overwritten)
It would be helpful to see the code which loads R14 and R15 and the
code between load and the code in your original post.
--
John Small
(remove the z's for email address)
| |
|
| Kelly Bert Manning wrote in message ...
>does that end up unpacking a single byte at the specified displacement?
>
>(padded with zeros to fill out the length specified for the right operand)
>
> CH R14,=H'2' TOO MANY CHARS?
> BL PARM5D NO, IT'S OKAY
> LA R14,2 YES, SET R14 TO 2
> SPACE 1
>PARM5D DS 0H
> BCTR R14,0 R14 = HEX LTH
At this point you should include a test for R14 negative.
> EX R14,PARM5EX PACK WAIT TIME
|
|
|
|
|