We are re-compiling in order to move to the new NSX systems. I've transitioned from ETK to NSDEE and ran into a weird assembler message that so far has everyone stumped including HP support.

Wondering if someone here has run into this. I am compiling in cygwin so NSDEE is out of the picture for now. Just running the cross compiler against a local version of the source that was sent to HP to troubleshoot with. Output below:
---------
$ ./makeit
MORE_FLAGS = ""
cwd is /cygdrive/c/Users/c055529/Projects/NSDEE/HPCase_CompileIssue/ai-tar
rm -f -fr ./objs/
rm -f -f savedsrc.*
COMP_ROOT = C:\Program Files (x86)\Compaq ETK-NSE\L22.09
mkdir -p ./objs
'C:\Program Files (x86)\Compaq ETK-NSE\L22.09/usr/bin/xptal' -suppress -nowarn=4281 -Wverbose -call_shared -Wsavetemps -o objs/savedsrc.o ./src/savedsrc.tal
xptal args: C:\Program Files (x86)\Compaq ETK-NSE\L22.09\usr\bin\xptal.exe -suppress -nowarn=4281 -Wverbose -call_shared -Wsavetemps -o objs/savedsrc.o ./src/savedsrc.tal

xptal: running "C:\Program Files (x86)\Compaq ETK-NSE\L22.09\usr\cmplr\xptalcom.exe" -XT"savedsrc.T" -XD"savedsrc.D" -XK"savedsrc.K" -EB -Xparams -X"C:\Users\c055529\Projec
ts\NSDEE\HPCase_CompileIssue\ai-tar\src\savedsrc.tal" -X,suppress -X,nowarn -X4281 -X,call_shared -Xend

xptal: running "C:\Program Files (x86)\Compaq ETK-NSE\L22.09\usr\cmplr\be.exe" -PHASE:c -G8 -O1 -LANG:=ptal -TARG:sse3=on -TARG:datamode=32 -TARG:processor=wolfdale -TARG:s
se2=on -TARG:mmx=on -TARG:sse=on -TARG:3dnow=off -TARG:sse4a=off -TENV:PIC -TARG:BEX=BE -TARG:abi=p64 -g -fT,savedsrc.T -s -fs,savedsrc.s savedsrc.tal

xptal: running "C:\Program Files (x86)\Compaq ETK-NSE\L22.09\usr\cmplr\xas.exe" -mlanguage=ptal -mcode-big-endian -mfloattype=neutral --fatal-warnings -lcf savedsrc.K -o ob
js/savedsrc.o savedsrc.s
savedsrc.s: Assembler messages:
savedsrc.s:5758: Internal Error: attempt to move .org backwards savedsrc.s:5767: Internal Error: attempt to move .org backwards savedsrc.s:5776: Internal Error: attempt to move .org backwards savedsrc.s:5787: Internal Error: attempt to move .org backwards savedsrc.s:5795: Internal Error: attempt to move .org backwards
Page 1 2023 March 23, 18:24:06


XPTAL T0879L01_15FEB2018_29OCT2018
Copyright (C) 2013-2015 Hewlett Packard Enterprise Development LP

Directives = ?,suppress ,nowarn 4281 ,call_shared

*** end of root source file ***

Page 2 2023 March 23, 18:24:06


------------------------------------------------------------------------------- XPTAL - Portable Transaction Application Language for TNS/X - T0879L01_15FEB2018_29OCT2018_AAG
No errors detected.
No warnings reported.
Number of source lines = 63954
Heap use by compiler front end (XTALCOM)
symbol pool: 532972
scope tables: 90972; 62060; 116368; 269400 (global; proc; subproc; total)
parse tree: 16739232
defines: 219596
xptal.exe: Exiting with status 3; 1 error(s).
make: *** [Makefile:25: objs/savedsrc.o] Error 3
**Failure**
----------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, March 23, 2023 at 1:52:46 p.m. UTC-4, SRSeedBurners wrote:

We are re-compiling in order to move to the new NSX systems. I've transitioned from ETK to NSDEE and ran into a weird assembler message that so far has everyone stumped including HP support.

Wondering if someone here has run into this. I am compiling in cygwin so NSDEE is out of the picture for now. Just running the cross compiler against a local version of the source that was sent to HP to troubleshoot with. Output below:
---------
$ ./makeit
MORE_FLAGS = ""
cwd is /cygdrive/c/Users/c055529/Projects/NSDEE/HPCase_CompileIssue/ai-tar rm -f -fr ./objs/
rm -f -f savedsrc.*
COMP_ROOT = C:\Program Files (x86)\Compaq ETK-NSE\L22.09
mkdir -p ./objs
'C:\Program Files (x86)\Compaq ETK-NSE\L22.09/usr/bin/xptal' -suppress -nowarn=4281 -Wverbose -call_shared -Wsavetemps -o objs/savedsrc.o ./src/savedsrc.tal
xptal args: C:\Program Files (x86)\Compaq ETK-NSE\L22.09\usr\bin\xptal.exe -suppress -nowarn=4281 -Wverbose -call_shared -Wsavetemps -o objs/savedsrc.o ./src/savedsrc.tal

xptal: running "C:\Program Files (x86)\Compaq ETK-NSE\L22.09\usr\cmplr\xptalcom.exe" -XT"savedsrc.T" -XD"savedsrc.D" -XK"savedsrc.K" -EB -Xparams -X"C:\Users\c055529\Projec
ts\NSDEE\HPCase_CompileIssue\ai-tar\src\savedsrc.tal" -X,suppress -X,nowarn -X4281 -X,call_shared -Xend

xptal: running "C:\Program Files (x86)\Compaq ETK-NSE\L22.09\usr\cmplr\be.exe" -PHASE:c -G8 -O1 -LANG:=ptal -TARG:sse3=on -TARG:datamode=32 -TARG:processor=wolfdale -TARG:s
se2=on -TARG:mmx=on -TARG:sse=on -TARG:3dnow=off -TARG:sse4a=off -TENV:PIC -TARG:BEX=BE -TARG:abi=p64 -g -fT,savedsrc.T -s -fs,savedsrc.s savedsrc.tal

xptal: running "C:\Program Files (x86)\Compaq ETK-NSE\L22.09\usr\cmplr\xas.exe" -mlanguage=ptal -mcode-big-endian -mfloattype=neutral --fatal-warnings -lcf savedsrc.K -o ob
js/savedsrc.o savedsrc.s
savedsrc.s: Assembler messages:
savedsrc.s:5758: Internal Error: attempt to move .org backwards savedsrc.s:5767: Internal Error: attempt to move .org backwards savedsrc.s:5776: Internal Error: attempt to move .org backwards savedsrc.s:5787: Internal Error: attempt to move .org backwards savedsrc.s:5795: Internal Error: attempt to move .org backwards
Page 1 2023 March 23, 18:24:06

XPTAL T0879L01_15FEB2018_29OCT2018
Copyright (C) 2013-2015 Hewlett Packard Enterprise Development LP

Directives = ?,suppress ,nowarn 4281 ,call_shared

*** end of root source file ***

Page 2 2023 March 23, 18:24:06

-------------------------------------------------------------------------------
XPTAL - Portable Transaction Application Language for TNS/X - T0879L01_15FEB2018_29OCT2018_AAG
No errors detected.
No warnings reported.
Number of source lines = 63954
Heap use by compiler front end (XTALCOM)
symbol pool: 532972
scope tables: 90972; 62060; 116368; 269400 (global; proc; subproc; total) parse tree: 16739232
defines: 219596
xptal.exe: Exiting with status 3; 1 error(s).
make: *** [Makefile:25: objs/savedsrc.o] Error 3
**Failure**
----------

Have you transitioned to the new cross compilers for NSDEE? They are generally in a different location from the one you have above (now in HPE NonStop\L22.09). Also, I am not sure but I do not think the execution of the assembler on its own is supported.
--Randall

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, March 24, 2023 at 2:21:30 PM UTC-5, Randall wrote:

Have you transitioned to the new cross compilers for NSDEE? They are generally in a different location from the one you have above (now in HPE NonStop\L22.09). Also, I am not sure but I do not think the execution of the assembler on its own is

supported.

--Randall

Cross-compilers: Yes, for some reason the install process puts them in the same directory as the old, or maybe I did that, don't remember. Notice below from my Eclipse environment it is from where I put the ISO.

Assembler execution: I'm not running that manually, eclipse is doing that:

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\xptalcom.exe" ...

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\be.exe"...

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\xas.exe" ...
C:\Users\c055529\AppData\Local\Temp\t230116.s: Assembler messages: C:\Users\c055529\AppData\Local\Temp\t230116.s:5793: Internal Error: attempt to move .org backwards
C:\Users\c055529\AppData\Local\Temp\t230116.s:5802: Internal Error: attempt to move .org backwards
Page 1 2023 March 29, 04:44:22

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, March 29, 2023 at 5:52:49 a.m. UTC-4, Steve Sterling wrote:

On Friday, March 24, 2023 at 2:21:30 PM UTC-5, Randall wrote:

Have you transitioned to the new cross compilers for NSDEE? They are generally in a different location from the one you have above (now in HPE NonStop\L22.09). Also, I am not sure but I do not think the execution of the assembler on its own is

supported.

--Randall

Cross-compilers: Yes, for some reason the install process puts them in the same directory as the old, or maybe I did that, don't remember. Notice below from my Eclipse environment it is from where I put the ISO.

Assembler execution: I'm not running that manually, eclipse is doing that:

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\xptalcom.exe" ...

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\be.exe"...

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\xas.exe" ...
C:\Users\c055529\AppData\Local\Temp\t230116.s: Assembler messages: C:\Users\c055529\AppData\Local\Temp\t230116.s:5793: Internal Error: attempt to move .org backwards
C:\Users\c055529\AppData\Local\Temp\t230116.s:5802: Internal Error: attempt to move .org backwards
Page 1 2023 March 29, 04:44:22

Get in touch with GNSC. This appears to be a defect.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 29 Mar 2023 11:53:25 -0700 (PDT), Randall <rsbecker@nexbridge.com> wrote:

On Wednesday, March 29, 2023 at 5:52:49?a.m. UTC-4, Steve Sterling wrote:

On Friday, March 24, 2023 at 2:21:30?PM UTC-5, Randall wrote:

Have you transitioned to the new cross compilers for NSDEE? They are generally in a different location from the one you have above (now in HPE NonStop\L22.09). Also, I am not sure but I do not think the execution of the assembler on its own is

supported.

--Randall

Cross-compilers: Yes, for some reason the install process puts them in the same directory as the old, or maybe I did that, don't remember. Notice below from my Eclipse environment it is from where I put the ISO.

Assembler execution: I'm not running that manually, eclipse is doing that: >>
xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\xptalcom.exe" ...

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\be.exe"...

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\xas.exe" ...
C:\Users\c055529\AppData\Local\Temp\t230116.s: Assembler messages:
C:\Users\c055529\AppData\Local\Temp\t230116.s:5793: Internal Error: attempt to move .org backwards
C:\Users\c055529\AppData\Local\Temp\t230116.s:5802: Internal Error: attempt to move .org backwards
Page 1 2023 March 29, 04:44:22

Get in touch with GNSC. This appears to be a defect.

Randall, he started the thread by stating 'so far has everyone stumped including HP support', so I assume there is already a case opened.

Steve, when HPE have a solution, please share. (I assume this was HPE support in your original post, not HP?)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, March 29, 2023 at 3:20:19 p.m. UTC-4, Bill Honaker wrote:

On Wed, 29 Mar 2023 11:53:25 -0700 (PDT), Randall <rsbe...@nexbridge.com> wrote:

On Wednesday, March 29, 2023 at 5:52:49?a.m. UTC-4, Steve Sterling wrote:

On Friday, March 24, 2023 at 2:21:30?PM UTC-5, Randall wrote:

Have you transitioned to the new cross compilers for NSDEE? They are generally in a different location from the one you have above (now in HPE NonStop\L22.09). Also, I am not sure but I do not think the execution of the assembler on its own is

supported.

--Randall

Cross-compilers: Yes, for some reason the install process puts them in the same directory as the old, or maybe I did that, don't remember. Notice below from my Eclipse environment it is from where I put the ISO.

Assembler execution: I'm not running that manually, eclipse is doing that:

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\xptalcom.exe" ...

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\be.exe"...

xptal: running "C:\Users\c055529\Projects\NSDEE\Product\ISO\CrossCompilers\807488-013_pTal\program files\HPE NonStop\L22.09\usr\cmplr\xas.exe" ...
C:\Users\c055529\AppData\Local\Temp\t230116.s: Assembler messages:
C:\Users\c055529\AppData\Local\Temp\t230116.s:5793: Internal Error: attempt to move .org backwards
C:\Users\c055529\AppData\Local\Temp\t230116.s:5802: Internal Error: attempt to move .org backwards
Page 1 2023 March 29, 04:44:22

Get in touch with GNSC. This appears to be a defect.

Randall, he started the thread by stating 'so far has everyone stumped including HP support', so I assume there is already a case opened.

Steve, when HPE have a solution, please share. (I assume this was HPE support in your original post, not HP?)

I am curious as to how large the source file is. Can it be shared with HPE? Does this happen when compiling on the NonStop using standard compilers? I suspect it will work. The error appears to be a code (or data) relocation problem in the assembler. If
I had to guess, this could be something relating to the big-endian generated code from the assembler that may not work properly when run on Windows because of the subtle differences in the memory registers for x86 (big vs. little).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

They found the problem code buried in some obscure utility code, i.e. I never would have found this and I have no idea how they managed to find it. I'm just blown away that they were able to find this.

Issue: "the xPTAL compiler mishandles empty moves"

Solution:
Change:
WORK ':=' ["" ]->@P;

To this:
@P := @WORK;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 3 Apr 2023 23:50:27 -0700 (PDT), SRSeedBurners <sterlingranch@gmail.com> wrote:

They found the problem code buried in some obscure utility code, i.e. I never would have found this and I have no idea how they managed to find it. I'm just blown away that they were able to find this.

Issue: "the xPTAL compiler mishandles empty moves"

Solution:
Change:
WORK ':=' ["" ]->@P;

To this:
@P := @WORK;

Congratulations on getting a fix, Steve. But you never shared the source that was offending the compiler...
The fix above would not seem to be an equivalent fix, as the result doesn't include the initialization.

Can you share a little more?
Bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, April 4, 2023 at 1:10:42 p.m. UTC-4, Bill Honaker wrote:

On Mon, 3 Apr 2023 23:50:27 -0700 (PDT), SRSeedBurners <sterli...@gmail.com> wrote:

They found the problem code buried in some obscure utility code, i.e. I never would have found this and I have no idea how they managed to find it. I'm just blown away that they were able to find this.

Issue: "the xPTAL compiler mishandles empty moves"

Solution:
Change:
WORK ':=' ["" ]->@P;

To this:
@P := @WORK;

Congratulations on getting a fix, Steve. But you never shared the source that was offending the compiler...
The fix above would not seem to be an equivalent fix, as the result doesn't include the initialization.

Can you share a little more?
Bill

I'm assuming that something like this would work:
Change:
WORK ':=' ["" ]->@P;

To this:
WORK ':=' ["" ];
@P := @WORK;

Yes?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, April 4, 2023 at 12:10:42 PM UTC-5, Bill Honaker wrote:

Congratulations on getting a fix, Steve. But you never shared the source that was offending the compiler...
The fix above would not seem to be an equivalent fix, as the result doesn't include the initialization.

Can you share a little more?
Bill

Bill,

I'm not a Tal guy but it's basically doing a copy empty string into WORK buffer:
-----------
STRING .P
STRING WORK[0:39];

CALL LB^FILLSTRUCT (WORK," "); ! Space fill work buffer

WORK ':=' ["" ]->@P; <-- breaks xpTAL compiler due to "mishandles empty moves"
-----------

Randall - this still breaks the compiler. HP stated there is a defect in the compiler they will fix and since I have a workaround it's probably just going to get added to some future regular release.

WORK ':=' ["" ];
@P := @WORK;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 4 Apr 2023 12:23:43 -0700 (PDT), SRSeedBurners <sterlingranch@gmail.com> wrote:

On Tuesday, April 4, 2023 at 12:10:42?PM UTC-5, Bill Honaker wrote:

Congratulations on getting a fix, Steve. But you never shared the source that was offending the compiler...
The fix above would not seem to be an equivalent fix, as the result doesn't include the initialization.

Can you share a little more?
Bill

Bill,

I'm not a Tal guy but it's basically doing a copy empty string into WORK buffer:
-----------
STRING .P
STRING WORK[0:39];

CALL LB^FILLSTRUCT (WORK," "); ! Space fill work buffer

WORK ':=' ["" ]->@P; <-- breaks xpTAL compiler due to "mishandles empty moves"
-----------

Randall - this still breaks the compiler. HP stated there is a defect in the compiler they will fix and since I have a workaround it's probably just going to get added to some future regular release.

WORK ':=' ["" ];
@P := @WORK;

Steve,

I recommend you find some alternative (pTAL Compiler-friendly) means of copying an empty string into the buffer.

However, as I read it, the [""] construct refers to an array (one long) of character arrays zero-long) which contains nothing.
TAL doesn't have the same context of an empty string that TAL does. The ':=' operator causes work[0] to get a pointer to
the internal array. -> The -> opearator puts the addres of the NEXT byte into P.

Without a more specific specification of what the code needs to do, you may need someting like this to copy an 'emptry (C) string'.

WORK [0] = 0; ! NULL BYTE
@P := @Work + 1;

Bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <8dfe7aef-72fd-4f0f-8ce4-82d025233982n@googlegroups.com>, sterlingranch@gmail.com says...

They found the problem code buried in some obscure utility code, i.e. I

never wo

uld have found this and I have no idea how they managed to find it. I'm

just bl

own away that they were able to find this.

Issue: "the xPTAL compiler mishandles empty moves"

Solution:
Change:
WORK ':=' ["" ]->@P;

To this:
@P := @WORK;

Does it only affect the cross compiler ?

This compiled with the host based xptal

PROC TALMAIN MAIN;
begin
string .ext work[0:31];
string .ext p;

WORK ':=' ["" ]->@P;

return;
end;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, April 4, 2023 at 5:00:27 PM UTC-5, Bill Honaker wrote:

Steve,

I recommend you find some alternative (pTAL Compiler-friendly) means of copying an empty string into the buffer.

Bill, this code was written before I even knew what a computer was!
DATE WRITTEN : NOVEMBER 1995

Some of this code in the system was written when I was in high skool!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 5 Apr 2023 07:24:25 -0700 (PDT), SRSeedBurners <sterlingranch@gmail.com> wrote:

On Tuesday, April 4, 2023 at 5:00:27?PM UTC-5, Bill Honaker wrote:

Steve,

I recommend you find some alternative (pTAL Compiler-friendly) means of copying an empty string into the buffer.

Bill, this code was written before I even knew what a computer was!
DATE WRITTEN : NOVEMBER 1995

Some of this code in the system was written when I was in high skool!

Steve, since you say that the host-resident compilers don't fail with this, but the Cross compilers do,
and that HPE is aware of the bug (and will be fixing it), I'd suggest that, for this program,
you just use the host compilers for a while. Otherwise you have some coding to do.

You could also run VPROC against the xptal compiler on the host and on Windows, and see if there
is a difference in the release dates/SPR numbers.

Have fun!
Bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)