Re: Compile error and also possible library bug with Metal/C metal.h
Another problem you have is you're not calling __cinit() [1] to
initialize the Metal/C environment so the call to malloc() will fail as
no heap has been created. You really must *always* check malloc() even
in a test driver.
[1]
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ccrug00/cinit.htm
On 12/01/2021 2:29 am, Dennis Fitzpatrick wrote:
I'm a developer working with a client to develop Metal C functions for their
products. Up until recently I've defined __METAL_STATIC and linked with
SCCR3BND. I decided recently to play with the dynamic library in LPALIB so I
removed that #define. What I'm getting is compile errors on the substitution
macros from metal.h. That is the first problem. I decided to try and circumvent
the compile errors and I think I found a bug in the memcmp library function.
That is the second problem. I'm really hoping someone will tell me I missed
something really obvious or missed some maintenance.
I created a trivial sample program to demonstrate:
/*
Sample for Metal C
*/
#include
#include
int main(int argc, char** argv)
{
char* xarg = "abcd";
void *mem = malloc(64);
memset(mem, 0x0f, 64);
memcpy(mem, xarg, sizeof(xarg));
int mcmp = memcmp(mem, xarg, sizeof(xarg));
free(mem);
}
Of course, this compiles and runs just fine on Visual Studio where I do my
initial development. On z/OS XLC though I get errors like the following:
12 | memset(mem, 0x0f, 64);
| 12
12 + ((___MEMSET * ) ( (*(struct __cvt_s * __ptr32 * __ptr32)16) ->
__cvtecvt -> __ecvtsdc -> __sdca\+ 12
===>
b...a.
*=ERROR===> a - CCN3275 Unexpected text ')' encountered.
*=ERROR===> b - CCN3045 Undeclared identifier ___MEMSET.
12 +libv31 -> __libfunc[33] ))(mem, 0x0f, 64);
+ 12
===>
.c
*=ERROR===> c - CCN3277 Syntax error: possible missing ')' or ','?
The header file include list is exactly what I expect:
1 /usr/include/metal/stdio.h
2 /usr/include/metal/metal.h
3 /usr/include/metal/stddef.h
4 /usr/include/metal/stdlib.h
5 /usr/include/metal/builtins.h
Looking through all of the layers in the metal.h header started me looking for
aspirin. I decided to push forward as an exercise by defining my own structures
to use the Metal C function vector. I already had many of the standard z/OS
structures mapped and added my own mapping of sys_libv31_s with real function
prototypes:
struct sys_libv31_s
{
void (*_em_0)();
int (*_em_abs)(int,int); // 1
int (*_em_atoi)(char*); // 2
long (*_em_atol)(char*); // 3
long long (*_em_atoll)(char*); // 4
void* (*_em_calloc)(size_t); // 5
And my own substitution macros to remove the metal.h definition and put in my
own EMCALL reference:
#define EMCALL(_t, _n) (##_t)(*(CVTPTR->CVTECVT->ECVTSDC->sdcalibv31->_em_##_n))
#define em_0 EMCALL(void, em_0)
#undef abs // 1
#define abs EMCALL(int, abs)
#undef atoi // 2
#define atoi EMCALL(int atoi)
#undef atol // 3
#define atol EMCALL(long, atol)
#undef atoll // 4
#define atoll EMCALL(long long, atoll)
#undef calloc // 5
#define calloc EMCALL(void *, calloc)
I can't give you the whole thing as it is too much to extract from client
proprietary material. Hopefully, this is enough to get the gist.
Now this is where I believe I found a bug in the memcmp function returning an
invalid result and also a potential S0C4. With getting all of my code to
compile I found things taking some weird code paths. I tracked it down to a
memcmp and setup the code in the sample above to test it. I found the memcmp
above returns an invalid result, 0x0f, even though the memory is equal. I went
into TEST and disassembled the code and got this:
1F24CD78.STM R14,R3,12(R13)
1F24CD7C.LR R15,R13
1F24CD7E.L R13,8(,R13)
1F24CD82.ST R15,4(,R13)
1F24CD86.STMHR14,R3,80(R13)
1F24CD8C.L R14,0(,R1)
1F24CD90.L R2,4(,R1)
1F24CD94.ICM R0,15,8(R1)
1F24CD98.BRC 8,*+52
1F24CD9C.LR R1,R0
1F24CD9E.LLGCR15,0(,R14)
1F24CDA4.LLGCR3,0(,R2)
1F24CDAA.LA R14,1(,R14)
1F24CDAE.LA R2,1(,R2)
1F24CDB2.CR R15,R3
1F24CDB4.BRC 7,*+36
1F24CDB8.LLGCR15,0(,R14)
1F24CDBE.LLGCR3,0(,R2)
1F24CDC4.BRCTR1,*-26
1F24CDC8.BRC 15,*+16
1F24CDCC.LLGCR15,0(,R14)
1F24CDD2.LLGCR3,0(,R2)
1F24CDD8.SLR R15,R3
1F24CDDA.LMH R14,R3,80(R13)
1F24CDE0.L R13,4(,R13)
Re: Compile error and also possible library bug with Metal/C metal.h
The BRC 7,*+36 is only going to branch if the condition code bits are 7.
LLGC doesnt change the condition code, so it would be set off a different
instruction.
Joe
On Mon, Jan 11, 2021 at 9:20 PM Dennis Fitzpatrick
wrote:
> Thanks for the string.h reference as that seems to have picked up the
> missing __MEMSET. I'm going to go back to my larger library of functions
> with my own header complications that wrap all of this up, and apply this
> and see what happens. I'll report back on that.
>
> You show option of LP64 with is a 64 bit compile while I'm defaulting to
> 32 bit. The sizeof as pointed out was incorrect but fortuitous since
> sizeof(xarg) is 4 (a 4 byte pointer) and the length I wanted to compare is
> 4 bytes. I should have just hard coded it for the sample. The Metal C
> library memcmp routine I show in the disassembly I believe still in error
> because it increments and then loads the data after the string runs out.
> That's the two LLGC instructions after BCR 7. They load the next bytes
> before testing in the BRCT that the memory area has run out. It computes
> the result value by subtracting the two bytes after the end of the memory.
> When I was calling the library routine nothing worked because of that. If I
> let it use to the builtin.h code my converted programs worked. I hope that
> makes sense.
>
>
>
>
> Dennis C. Fitzpatrick
> den...@dcfitz.com
> H: 630.325.6184
> W: 630.325.6137
> M: 630.660.8040
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Joe Monk
> Sent: Monday, January 11, 2021 6:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Compile error and also possible library bug with Metal/C
> metal.h
>
> "I'd be perfectly happy for someone to tell me I missed some obvious
> compiler option or did something else really stupid."
>
> Found this on another website ...
>
> The issue was with the search order. Although I did
> search(/usr/metal/include) from with in my JCL I didn't proceed it with a
> nosearch option, so string.h was getting picked up from the standard system
> libraries instead of the version included with Metal C. I've pasted my
> optfile dataset I passed to the CPARM below for reference.
>
> //OPTIONS DD *
> SO
> LIST
> LONG
> NOXREF
> CSECT
> METAL
> LP64
> NOSEARCH
> search(/usr/include/metal/)
>
> Joe
>
> On Mon, Jan 11, 2021 at 12:39 PM Dennis Fitzpatrick
> wrote:
>
> > I'm a developer working with a client to develop Metal C functions for
> > their products. Up until recently I've defined __METAL_STATIC and
> > linked with SCCR3BND. I decided recently to play with the dynamic
> > library in LPALIB so I removed that #define. What I'm getting is
> > compile errors on the substitution macros from metal.h. That is the
> > first problem. I decided to try and circumvent the compile errors and
> > I think I found a bug in the memcmp library function. That is the
> > second problem. I'm really hoping someone will tell me I missed
> > something really obvious or missed some maintenance.
> >
> > I created a trivial sample program to demonstrate:
> >
> > /*
> > Sample for Metal C
> > */
> >
> > #include
> > #include
> >
> > int main(int argc, char** argv)
> > {
> > char* xarg = "abcd";
> > void *mem = malloc(64);
> > memset(mem, 0x0f, 64);
> > memcpy(mem, xarg, sizeof(xarg));
> > int mcmp = memcmp(mem, xarg, sizeof(xarg));
> > free(mem);
> > }
> > Of course, this compiles and runs just fine on Visual Studio where I
> > do my initial development. On z/OS XLC though I get errors like the
> following:
> >
> > 12 | memset(mem, 0x0f, 64);
> > | 12
> > 12 + ((___MEMSET * ) ( (*(struct __cvt_s * __ptr32 *
> > __ptr32)16) -> __cvtecvt -> __ecvtsdc -> __sdca\+ 12
> > ===>
> >
> b...a.
> > *=ERROR===> a - CCN3275 Unexpected text ')' encountered.
> > *=ERROR===> b - CCN3045 Undeclared identifier ___MEMSET.
> > 12 +libv31 -> __libfunc[33] ))(mem, 0x0f, 64);
> > + 12
> > ===>
> >
> .c
> > *=ERROR===> c - CCN3277 Syntax error: possible missing ')' or
> ','?
> >
> > The header file include list is exactly what I expect:
> >
> >
Re: Compile error and also possible library bug with Metal/C metal.h
Thanks for the string.h reference as that seems to have picked up the missing
__MEMSET. I'm going to go back to my larger library of functions with my own
header complications that wrap all of this up, and apply this and see what
happens. I'll report back on that.
You show option of LP64 with is a 64 bit compile while I'm defaulting to 32
bit. The sizeof as pointed out was incorrect but fortuitous since sizeof(xarg)
is 4 (a 4 byte pointer) and the length I wanted to compare is 4 bytes. I should
have just hard coded it for the sample. The Metal C library memcmp routine I
show in the disassembly I believe still in error because it increments and
then loads the data after the string runs out. That's the two LLGC instructions
after BCR 7. They load the next bytes before testing in the BRCT that the
memory area has run out. It computes the result value by subtracting the two
bytes after the end of the memory. When I was calling the library routine
nothing worked because of that. If I let it use to the builtin.h code my
converted programs worked. I hope that makes sense.
Dennis C. Fitzpatrick
den...@dcfitz.com
H: 630.325.6184
W: 630.325.6137
M: 630.660.8040
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Joe
Monk
Sent: Monday, January 11, 2021 6:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compile error and also possible library bug with Metal/C metal.h
"I'd be perfectly happy for someone to tell me I missed some obvious compiler
option or did something else really stupid."
Found this on another website ...
The issue was with the search order. Although I did
search(/usr/metal/include) from with in my JCL I didn't proceed it with a
nosearch option, so string.h was getting picked up from the standard system
libraries instead of the version included with Metal C. I've pasted my optfile
dataset I passed to the CPARM below for reference.
//OPTIONS DD *
SO
LIST
LONG
NOXREF
CSECT
METAL
LP64
NOSEARCH
search(/usr/include/metal/)
Joe
On Mon, Jan 11, 2021 at 12:39 PM Dennis Fitzpatrick
wrote:
> I'm a developer working with a client to develop Metal C functions for
> their products. Up until recently I've defined __METAL_STATIC and
> linked with SCCR3BND. I decided recently to play with the dynamic
> library in LPALIB so I removed that #define. What I'm getting is
> compile errors on the substitution macros from metal.h. That is the
> first problem. I decided to try and circumvent the compile errors and
> I think I found a bug in the memcmp library function. That is the
> second problem. I'm really hoping someone will tell me I missed
> something really obvious or missed some maintenance.
>
> I created a trivial sample program to demonstrate:
>
> /*
> Sample for Metal C
> */
>
> #include
> #include
>
> int main(int argc, char** argv)
> {
> char* xarg = "abcd";
> void *mem = malloc(64);
> memset(mem, 0x0f, 64);
> memcpy(mem, xarg, sizeof(xarg));
> int mcmp = memcmp(mem, xarg, sizeof(xarg));
> free(mem);
> }
> Of course, this compiles and runs just fine on Visual Studio where I
> do my initial development. On z/OS XLC though I get errors like the following:
>
> 12 | memset(mem, 0x0f, 64);
> | 12
> 12 + ((___MEMSET * ) ( (*(struct __cvt_s * __ptr32 *
> __ptr32)16) -> __cvtecvt -> __ecvtsdc -> __sdca\+ 12
> ===>
> b...a.
> *=ERROR===> a - CCN3275 Unexpected text ')' encountered.
> *=ERROR===> b - CCN3045 Undeclared identifier ___MEMSET.
> 12 +libv31 -> __libfunc[33] ))(mem, 0x0f, 64);
> + 12
> ===>
> .c
> *=ERROR===> c - CCN3277 Syntax error: possible missing ')' or ','?
>
> The header file include list is exactly what I expect:
>
> 1 /usr/include/metal/stdio.h
> 2 /usr/include/metal/metal.h
> 3 /usr/include/metal/stddef.h
> 4 /usr/include/metal/stdlib.h
> 5 /usr/include/metal/builtins.h
>
> Looking through all of the layers in the metal.h header started me
> looking for aspirin. I decided to push forward as an exercise by
> defining my own structures to use the Metal C function vector. I
> already had many of the standard z/OS structures mapped and added my
> own mapping of sys_libv31_s with real function prototypes:
>
> struct sys_libv31_s
> {
> void (*_em_0)();
> int (*_em_abs)(int,int); // 1
> int (*_
Re: Compile error and also possible library bug with Metal/C metal.h
"I'd be perfectly happy for someone to tell me I missed some obvious
compiler option or did something else really stupid."
Found this on another website ...
The issue was with the search order. Although I did
search(/usr/metal/include) from with in my JCL I didn't proceed it with a
nosearch option, so string.h was getting picked up from the standard system
libraries instead of the version included with Metal C. I've pasted my
optfile dataset I passed to the CPARM below for reference.
//OPTIONS DD *
SO
LIST
LONG
NOXREF
CSECT
METAL
LP64
NOSEARCH
search(/usr/include/metal/)
Joe
On Mon, Jan 11, 2021 at 12:39 PM Dennis Fitzpatrick
wrote:
> I'm a developer working with a client to develop Metal C functions for
> their products. Up until recently I've defined __METAL_STATIC and linked
> with SCCR3BND. I decided recently to play with the dynamic library in
> LPALIB so I removed that #define. What I'm getting is compile errors on the
> substitution macros from metal.h. That is the first problem. I decided to
> try and circumvent the compile errors and I think I found a bug in the
> memcmp library function. That is the second problem. I'm really hoping
> someone will tell me I missed something really obvious or missed some
> maintenance.
>
> I created a trivial sample program to demonstrate:
>
> /*
> Sample for Metal C
> */
>
> #include
> #include
>
> int main(int argc, char** argv)
> {
> char* xarg = "abcd";
> void *mem = malloc(64);
> memset(mem, 0x0f, 64);
> memcpy(mem, xarg, sizeof(xarg));
> int mcmp = memcmp(mem, xarg, sizeof(xarg));
> free(mem);
> }
> Of course, this compiles and runs just fine on Visual Studio where I do my
> initial development. On z/OS XLC though I get errors like the following:
>
> 12 | memset(mem, 0x0f, 64);
> | 12
> 12 + ((___MEMSET * ) ( (*(struct __cvt_s * __ptr32 *
> __ptr32)16) -> __cvtecvt -> __ecvtsdc -> __sdca\+ 12
> ===>
> b...a.
> *=ERROR===> a - CCN3275 Unexpected text ')' encountered.
> *=ERROR===> b - CCN3045 Undeclared identifier ___MEMSET.
> 12 +libv31 -> __libfunc[33] ))(mem, 0x0f, 64);
> + 12
> ===>
> .c
> *=ERROR===> c - CCN3277 Syntax error: possible missing ')' or ','?
>
> The header file include list is exactly what I expect:
>
> 1 /usr/include/metal/stdio.h
> 2 /usr/include/metal/metal.h
> 3 /usr/include/metal/stddef.h
> 4 /usr/include/metal/stdlib.h
> 5 /usr/include/metal/builtins.h
>
> Looking through all of the layers in the metal.h header started me looking
> for aspirin. I decided to push forward as an exercise by defining my own
> structures to use the Metal C function vector. I already had many of the
> standard z/OS structures mapped and added my own mapping of sys_libv31_s
> with real function prototypes:
>
> struct sys_libv31_s
> {
> void (*_em_0)();
> int (*_em_abs)(int,int); // 1
> int (*_em_atoi)(char*); // 2
> long (*_em_atol)(char*); // 3
> long long (*_em_atoll)(char*); // 4
> void* (*_em_calloc)(size_t); // 5
>
> And my own substitution macros to remove the metal.h definition and put in
> my own EMCALL reference:
>
> #define EMCALL(_t, _n)
> (##_t)(*(CVTPTR->CVTECVT->ECVTSDC->sdcalibv31->_em_##_n))
> #define em_0 EMCALL(void, em_0)
> #undef abs // 1
> #define abs EMCALL(int, abs)
> #undef atoi // 2
> #define atoi EMCALL(int atoi)
> #undef atol // 3
> #define atol EMCALL(long, atol)
> #undef atoll // 4
> #define atoll EMCALL(long long, atoll)
> #undef calloc // 5
> #define calloc EMCALL(void *, calloc)
>
> I can't give you the whole thing as it is too much to extract from client
> proprietary material. Hopefully, this is enough to get the gist.
>
> Now this is where I believe I found a bug in the memcmp function returning
> an invalid result and also a potential S0C4. With getting all of my code to
> compile I found things taking some weird code paths. I tracked it down to a
> memcmp and setup the code in the sample above to test it. I found the
> memcmp above returns an invalid result, 0x0f, even though the memory is
> equal. I went into TEST and disassembled the code and got this:
>
>
> 1F24CD78.STM R14,R3,12(R13)
>
> 1F24CD7C.LR R15,R13
>
> 1F24CD7E.L R13,8(,R13)
>
> 1F24CD82.ST R15,4(,R13)
>
> 1F24CD86.STMHR14,R3,80(R13)
>
> 1F24CD8C.L R14,0(,R1)
>
> 1F24CD90.L R2,4(,R1)
>
> 1F24CD94.ICM R0,15,8(R1)
>
> 1F24CD98.BRC 8,*+52
>
> 1F24CD9C.LR R1,R0
>
> 1F24CD9E.LLGCR15,0(,R14)
>
> 1F24CDA4.LLGCR3,0(,R2)
>
> 1F24CDAA.LA
Re: Compile error and also possible library bug with Metal/C metal.h
The sizeof() a char* in any C implementation is the size of an address (4, 8, or formerly 2 bytes). A char* IS an address, of course. sizeof() is resolved at compile time. If you think about it, there is no way the compiler could know how long a string a char* is going to be pointing to. That's why you need strlen(), which is a run time function. If you look in the compiler library doc it should for memcpy() tell you the required header and any required macro switches. For the "regular" C that is #include . Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras Sent: Monday, January 11, 2021 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Compile error and also possible library bug with Metal/C metal.h I've never used Metal C, but for the first problem (undeclared __MEMSET), I would look to see if there's a string.h that can be used. That's normally where memcmp is defined. As for the runtime problem, I'd guess it had something to do with using 'sizeof' incorrectly. It looks as if you are compiling 64-bit which would mean that 'sizeof(xarg)' is going to be 8. If you replace all the sizeofs with strlens, I think you'd see it work. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Compile error and also possible library bug with Metal/C metal.h
I've never used Metal C, but for the first problem (undeclared __MEMSET), I
would look to see if there's a string.h that can be used. That's normally
where memcmp is defined.
As for the runtime problem, I'd guess it had something to do with using
'sizeof' incorrectly. It looks as if you are compiling 64-bit which would
mean that 'sizeof(xarg)' is going to be 8. If you replace all the sizeofs
with strlens, I think you'd see it work.
In article
you wrote:
> I'm a developer working with a client to develop Metal C functions for their
> products. Up until recently I've defined __METAL_STATIC and linked with
> SCCR3BND. I decided recently to play with the dynamic library in LPALIB so I
> removed that #define. What I'm getting is compile errors on the substitution
> macros from metal.h. That is the first problem. I decided to try and
> circumvent the compile errors and I think I found a bug in the memcmp library
> function. That is the second problem. I'm really hoping someone will tell me
> I missed something really obvious or missed some maintenance.
> I created a trivial sample program to demonstrate:
> /*
> Sample for Metal C
> */
> #include
> #include
> int main(int argc, char** argv)
> {
> char* xarg = "abcd";
> void *mem = malloc(64);
> memset(mem, 0x0f, 64);
> memcpy(mem, xarg, sizeof(xarg));
> int mcmp = memcmp(mem, xarg, sizeof(xarg));
> free(mem);
> }
--
Don Poitras
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Compile error and also possible library bug with Metal/C metal.h
I'm a developer working with a client to develop Metal C functions for their
products. Up until recently I've defined __METAL_STATIC and linked with
SCCR3BND. I decided recently to play with the dynamic library in LPALIB so I
removed that #define. What I'm getting is compile errors on the substitution
macros from metal.h. That is the first problem. I decided to try and circumvent
the compile errors and I think I found a bug in the memcmp library function.
That is the second problem. I'm really hoping someone will tell me I missed
something really obvious or missed some maintenance.
I created a trivial sample program to demonstrate:
/*
Sample for Metal C
*/
#include
#include
int main(int argc, char** argv)
{
char* xarg = "abcd";
void *mem = malloc(64);
memset(mem, 0x0f, 64);
memcpy(mem, xarg, sizeof(xarg));
int mcmp = memcmp(mem, xarg, sizeof(xarg));
free(mem);
}
Of course, this compiles and runs just fine on Visual Studio where I do my
initial development. On z/OS XLC though I get errors like the following:
12 | memset(mem, 0x0f, 64);
| 12
12 + ((___MEMSET * ) ( (*(struct __cvt_s * __ptr32 * __ptr32)16) ->
__cvtecvt -> __ecvtsdc -> __sdca\+ 12
===>
b...a.
*=ERROR===> a - CCN3275 Unexpected text ')' encountered.
*=ERROR===> b - CCN3045 Undeclared identifier ___MEMSET.
12 +libv31 -> __libfunc[33] ))(mem, 0x0f, 64);
+ 12
===>
.c
*=ERROR===> c - CCN3277 Syntax error: possible missing ')' or ','?
The header file include list is exactly what I expect:
1 /usr/include/metal/stdio.h
2 /usr/include/metal/metal.h
3 /usr/include/metal/stddef.h
4 /usr/include/metal/stdlib.h
5 /usr/include/metal/builtins.h
Looking through all of the layers in the metal.h header started me looking for
aspirin. I decided to push forward as an exercise by defining my own structures
to use the Metal C function vector. I already had many of the standard z/OS
structures mapped and added my own mapping of sys_libv31_s with real function
prototypes:
struct sys_libv31_s
{
void (*_em_0)();
int (*_em_abs)(int,int); // 1
int (*_em_atoi)(char*); // 2
long (*_em_atol)(char*); // 3
long long (*_em_atoll)(char*); // 4
void* (*_em_calloc)(size_t); // 5
And my own substitution macros to remove the metal.h definition and put in my
own EMCALL reference:
#define EMCALL(_t, _n) (##_t)(*(CVTPTR->CVTECVT->ECVTSDC->sdcalibv31->_em_##_n))
#define em_0 EMCALL(void, em_0)
#undef abs // 1
#define abs EMCALL(int, abs)
#undef atoi // 2
#define atoi EMCALL(int atoi)
#undef atol // 3
#define atol EMCALL(long, atol)
#undef atoll // 4
#define atoll EMCALL(long long, atoll)
#undef calloc // 5
#define calloc EMCALL(void *, calloc)
I can't give you the whole thing as it is too much to extract from client
proprietary material. Hopefully, this is enough to get the gist.
Now this is where I believe I found a bug in the memcmp function returning an
invalid result and also a potential S0C4. With getting all of my code to
compile I found things taking some weird code paths. I tracked it down to a
memcmp and setup the code in the sample above to test it. I found the memcmp
above returns an invalid result, 0x0f, even though the memory is equal. I went
into TEST and disassembled the code and got this:
1F24CD78.STM R14,R3,12(R13)
1F24CD7C.LR R15,R13
1F24CD7E.L R13,8(,R13)
1F24CD82.ST R15,4(,R13)
1F24CD86.STMHR14,R3,80(R13)
1F24CD8C.L R14,0(,R1)
1F24CD90.L R2,4(,R1)
1F24CD94.ICM R0,15,8(R1)
1F24CD98.BRC 8,*+52
1F24CD9C.LR R1,R0
1F24CD9E.LLGCR15,0(,R14)
1F24CDA4.LLGCR3,0(,R2)
1F24CDAA.LA R14,1(,R14)
1F24CDAE.LA R2,1(,R2)
1F24CDB2.CR R15,R3
1F24CDB4.BRC 7,*+36
1F24CDB8.LLGCR15,0(,R14)
1F24CDBE.LLGCR3,0(,R2)
1F24CDC4.BRCTR1,*-26
1F24CDC8.BRC 15,*+16
1F24CDCC.LLGCR15,0(,R14)
1F24CDD2.LLGCR3,0(,R2)
1F24CDD8.SLR R15,R3
1F24CDDA.LMH R14,R3,80(R13)
1F24CDE0.L R13,4(,R13)
1F24CDE4.L R14,12(,R13)
1F24CDE8.LM R1,R3,24(R13)
1F24CDEC.BCR 15,R14
The important thing is that the loop uses R14 & R2 as the character pointers
and R1 as the count. The loop at D9E loads the first bytes of each memory area.
Then it increments the pointers, does the compare, and if NE branches to *+36
(DCC). It then reloads R15 & R3 but the pointers have already been
