LIB$INSV X86 bug?

[ndcsupport]

On X86, LIB$INSV is giving an ACCVIO on a simple call.

The following C code works as expected on IA64, but ACCVIO's on X86.

I've tried compiling the C code with /POINTER=LONG but that made no difference.

Code: Select all

main()
{
int src = 1 ;   /* Insert a 1 */
int pos = -1 ;  /* 1 bit back */
int siz = 1 ;   /* 1 bit */
char dst[4] ;   /* destination */

/* point just past dst[1] */
  char* dstptr = &dst[ 2 ] ;

/* Zero dst[1] for clarity */
  dst[ 1 ] = 0 ;

/* Insert into last bit of dst[1] */
  lib$insv( &src ,&pos ,&siz ,dstptr ) ;
}

Code: Select all

x> run testinsv
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=800000000000
0000, PC=FFFF83000998242A, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image     module    routine               line      rel PC           abs PC
LIBRTL  $1$DGA7215:[LIBRTL_4.SRC]LIBINSV.MAR;1
                                          #197 000000008013542A FFFF83000998242A
TESTINSV  TESTINSV  main                     9 0000000000000035 0000000080000035
TESTINSV  TESTINSV  __main                   1 00000000000000A3 00000000800000A3
                                             0 FFFF8300081FC0A6 FFFF8300081FC0A6
DCL                                          0 000000008006778B 000000007ADFF78B
%TRACE-I-LINENUMBER, Leading '#' specifies a source file record number.
%TRACE-I-END, end of TRACE stack dump

Is this an X86 bug in LIB$INSV, or am I missing something?

The code works on X86 for bit-positions that are positive.

Perhaps on X86, LIB$INSV isn't coded to handle negative bit positions?

Thanks, Don

[jreagan]

LIB$INSV is written in Macro and is literally

Code: Select all

00000004              00000000      105         SOURCE = 4                              ; Adr. of source
00000008              00000000      106         POSITION = 8                            ; Adr. of beginning position
0000000C              00000000      107         SIZE = 12                               ; Adr. of size to insert
00000010              00000000      108         BASE = 16                               ; Adr. of base to insert into

                      00000000      139         .enable quadword
                      00000000      140
                      00000000      141         .call_entry     label     = LIB$INSV, -
                      00000000      170                         preserve  = <>, -
                      00000000      171                         quad_args = TRUE
                      00000002      196
                      00000002      197         INSV    @SOURCE(AP), @POSITION(AP), -
                      00000002      198                 @SIZE(AP), @BASE(AP)            ; insert source field
                      0000000B      199         RET

I don't have any reports of INSV being broken (and we use it everywhere of course). I don't think many people call LIB$INSV however. I'll get someone to triage it. Did you use any qualifiers on the CC command?

[hein]

EDIT: Ooops, my bad. I scanned the documentation too fast and missed the "and the field is contained in the registers" Bit positon has no limit as such. The source width/size does "The maximum size is 32 bits". On reflection I have used larger bit position for arrays with non-byte length elements, and well as just to address bits in RMS FABs & RAB through COBOL. It just would not occur to me to use a negative position, but I cannot find documentation to the contrary

It seems to me this is a very bad coding practice deserving of a "reserved operand fault", but accvio is fine as well.
Bit positions as 0 .. <width - 1> , not negative.

If it works in I64 than that might just be BAD luck. Does it work with the real INSV instruction on VAX ?

Please go back to evaluate what the code is really meant to to an come up with supportable, and understandable alternative.

Describe the intent here if need be. Don't waste engineering cycles on this.

Just an opinion from the peanut gallery.

Hein

[ndcsupport]

Thanks John!

For this simple C test program, I just used:

CC/DEBUG/LIST/SHOW=ALL TESTINSV.C

I also just tried a simple Macro program. It works with a positive Position arg, but fails with a negative Position arg.

Code: Select all

.psect  data wrt,noshr,noexe,quad

dest:   .BLKL 2
one:    .long   1
minus1: .long   -1
msg:    .ascid  /Success/

.psect  code nowrt,shr,exe,quad

.ENTRY  TEST,0

; This works ...
        pushab  dest+4      ; Base
        pushal  one             ; Size
        pushal  one             ; Pos
        pushal  one             ; Source
        calls   #4,lib$insv
        pushal  msg
        calls   #1,lib$put_output

; This ACCVIO's ...
        pushab  dest+4      ; Base
        pushal  one             ; Size
        pushal  minus1        ; Pos
        pushal  one             ; Source
        calls   #4,lib$insv
        pushal  msg
        calls   #1,lib$put_output

        movl    #1,r0
        ret

.END    TEST

Code: Select all

x> run tinsv/nodeb
Success
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=800000000000
0000, PC=FFFF83000998242A, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image     module    routine               line      rel PC           abs PC
LIBRTL  $1$DGA7215:[LIBRTL_4.SRC]LIBINSV.MAR;1
                                          #197 000000008013542A FFFF83000998242A
TINSV  DKA100:[PWQ.LIC]TINSV.MAR;7         #26 00000000800000C5 00000000800000C5
                                             0 FFFF8300081FC0A6 FFFF8300081FC0A6
DCL                                          0 000000008006778B 000000007ADFF78B
%TRACE-I-LINENUMBER, Leading '#' specifies a source file record number.
%TRACE-I-END, end of TRACE stack dump

Looks like perhaps the INSV instruction hasn't been coded to handle negative positions?

Added in 55 minutes 18 seconds:

It seems to me this is a very bad coding practice deserving of a "reserved operand fault", but accvio is fine as well.
Bit positions as 0 .. <width - 1> , not negative.

If it works in I64 than that might just be BAD luck. Does it work with the real INSV instruction on VAX ?

Please go back to evaluate what the code is really meant to to an come up with supportable, and understandable alternative.

Describe the intent here if need be. Don't waste engineering cycles on this.

Just an opinion from the peanut gallery.

Hein

Dear Hein,

FYI

The VAX variable-bit-field instructions are designed to work on contiguous memory locations. Negative positions are allowed and target bits to the "left" of the base address. For a large array of bytes, one could use any integer value for the position, such as a position of -200 to affect the bits in a lower byte than the base address, or 200 to affect bits at a higher byte than the base.

Position is restricted to 0-31 only if the base is a 32-bit register.

Sincerely, Don