Discussion:
BLISS ALPHA_REGISTER_MAPPING messages
(too old to reply)
j***@gmail.com
2017-06-11 10:14:35 UTC
Permalink
Raw Message
BLISS qualifier /ALPHA_REGISTER_MAPPING generates a terminal message:

%BLS32-I-TEXT, Alpha Register Mapping enabled by the command line

Similar message is produced by the command SWITCHES
in the sys$library:ARCH_DEFS.REQ file:

%IF IA64 %THEN SWITCHES ALPHA_REGISTER_MAPPING; %FI
............................^
%BLS32-I-TEXT, Alpha Register Mapping enabled
at line number 26 in file SYS$COMMON:[SYSLIB]ARCH_DEFS.REQ;1

The project consists of ~250 modules, so these useless information
forces more important errors and warnings out of the terminal.
Is there any way how to suppress these messages selectively ?
BLISS /TERMINAL=NOERRORS qualifier can supress all messages,
but I'd like to see at least errors and warnings.

I've found a workaround, but it seems slow and ugly:

pipe BLISS/ALPHA .... | sear sys$input /ma=nor "%BLS32-I-TEXT, Alpha Register Mapping"

Any ideas ?
Jiri

BTW, why the PIPE command puts an additional end of line to the terminal ?
John Reagan
2017-06-11 12:11:28 UTC
Permalink
Raw Message
Post by j***@gmail.com
%BLS32-I-TEXT, Alpha Register Mapping enabled by the command line
Similar message is produced by the command SWITCHES
%IF IA64 %THEN SWITCHES ALPHA_REGISTER_MAPPING; %FI
............................^
%BLS32-I-TEXT, Alpha Register Mapping enabled
at line number 26 in file SYS$COMMON:[SYSLIB]ARCH_DEFS.REQ;1
The project consists of ~250 modules, so these useless information
forces more important errors and warnings out of the terminal.
Is there any way how to suppress these messages selectively ?
BLISS /TERMINAL=NOERRORS qualifier can supress all messages,
but I'd like to see at least errors and warnings.
pipe BLISS/ALPHA .... | sear sys$input /ma=nor "%BLS32-I-TEXT, Alpha Register Mapping"
Any ideas ?
Jiri
I'm 99.99% sure there is no way to suppress that message, but I'll look at the sources tomorrow. It was originally added as a reminder to the OpenVMS engineers that any register numbers in LINKAGE declarations are to be mapped to different Itanium registers using the same mapping that the Macro-32 compiler users.

You don't need the qualifier if you aren't using LINKAGEs. Even if you are using LINKAGEs, you can create Itanium specific linkages if you pick different register numbers (you have to know about the Calling Standard to do that) and omit the qualifier.

I didn't actually add this message but was part of the conversation. I lobbied for it to be the default and not have a message, but others thought it was a good idea.
John Reagan
2017-06-12 13:23:59 UTC
Permalink
Raw Message
Post by John Reagan
Post by j***@gmail.com
%BLS32-I-TEXT, Alpha Register Mapping enabled by the command line
Similar message is produced by the command SWITCHES
%IF IA64 %THEN SWITCHES ALPHA_REGISTER_MAPPING; %FI
............................^
%BLS32-I-TEXT, Alpha Register Mapping enabled
at line number 26 in file SYS$COMMON:[SYSLIB]ARCH_DEFS.REQ;1
The project consists of ~250 modules, so these useless information
forces more important errors and warnings out of the terminal.
Is there any way how to suppress these messages selectively ?
BLISS /TERMINAL=NOERRORS qualifier can supress all messages,
but I'd like to see at least errors and warnings.
pipe BLISS/ALPHA .... | sear sys$input /ma=nor "%BLS32-I-TEXT, Alpha Register Mapping"
Any ideas ?
Jiri
I'm 99.99% sure there is no way to suppress that message, but I'll look at the sources tomorrow. It was originally added as a reminder to the OpenVMS engineers that any register numbers in LINKAGE declarations are to be mapped to different Itanium registers using the same mapping that the Macro-32 compiler users.
You don't need the qualifier if you aren't using LINKAGEs. Even if you are using LINKAGEs, you can create Itanium specific linkages if you pick different register numbers (you have to know about the Calling Standard to do that) and omit the qualifier.
I didn't actually add this message but was part of the conversation. I lobbied for it to be the default and not have a message, but others thought it was a good idea.
I looked at the source. I don't see a way to disable it. Sorry.
David Froble
2017-06-12 16:41:15 UTC
Permalink
Raw Message
Post by John Reagan
I looked at the source. I don't see a way to disable it. Sorry.
I've got to wonder how many understand what's just happened? How often can
someone get an answer to such a question? I'm betting if it was directed to HPE
there would never be a response.

Thank you John for what you do.

And thanks to VSI for being what they are.

I'm thinking this is another reason for choosing VMS and VSI.
Hans Vlems
2017-06-12 20:06:43 UTC
Permalink
Raw Message
My own thought exactly! The last time I'd heard anything like that must have been at a DECUS symposium, 30 years ago. (SNA gateway product iirc)
Hans
John Reagan
2017-06-13 12:11:03 UTC
Permalink
Raw Message
Post by David Froble
Post by John Reagan
I looked at the source. I don't see a way to disable it. Sorry.
I've got to wonder how many understand what's just happened? How often can
someone get an answer to such a question? I'm betting if it was directed to HPE
there would never be a response.
Thank you John for what you do.
You are welcome.
V***@SendSpamHere.ORG
2017-06-13 13:15:09 UTC
Permalink
Raw Message
Post by David Froble
Post by John Reagan
I looked at the source. I don't see a way to disable it. Sorry.
I've got to wonder how many understand what's just happened? How often can
someone get an answer to such a question? I'm betting if it was directed to HPE
there would never be a response.
Thank you John for what you do.
And thanks to VSI for being what they are.
I'm thinking this is another reason for choosing VMS and VSI.
;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
j***@gmail.com
2017-06-13 12:29:10 UTC
Permalink
Raw Message
Post by John Reagan
Post by John Reagan
Post by j***@gmail.com
%BLS32-I-TEXT, Alpha Register Mapping enabled by the command line
Similar message is produced by the command SWITCHES
%IF IA64 %THEN SWITCHES ALPHA_REGISTER_MAPPING; %FI
............................^
%BLS32-I-TEXT, Alpha Register Mapping enabled
at line number 26 in file SYS$COMMON:[SYSLIB]ARCH_DEFS.REQ;1
The project consists of ~250 modules, so these useless information
forces more important errors and warnings out of the terminal.
Is there any way how to suppress these messages selectively ?
BLISS /TERMINAL=NOERRORS qualifier can supress all messages,
but I'd like to see at least errors and warnings.
pipe BLISS/ALPHA .... | sear sys$input /ma=nor "%BLS32-I-TEXT, Alpha Register Mapping"
Any ideas ?
Jiri
I'm 99.99% sure there is no way to suppress that message, but I'll look at the sources tomorrow. It was originally added as a reminder to the OpenVMS engineers that any register numbers in LINKAGE declarations are to be mapped to different Itanium registers using the same mapping that the Macro-32 compiler users.
You don't need the qualifier if you aren't using LINKAGEs. Even if you are using LINKAGEs, you can create Itanium specific linkages if you pick different register numbers (you have to know about the Calling Standard to do that) and omit the qualifier.
I didn't actually add this message but was part of the conversation. I lobbied for it to be the default and not have a message, but others thought it was a good idea.
I looked at the source. I don't see a way to disable it. Sorry.
Thanks for your effort.
After adding hundred ALIAS atributes to avoid the rest of %BLS32-I-TEXT messages, the PIPE command with four-line DCL filter script solved the issue. It is fast enough now.
Stephen Hoffman
2017-06-12 17:26:07 UTC
Permalink
Raw Message
OpenVMS development and more than a few other entities post-process the
compiler-generated files, masking out the expected errors and flagging
new ones.

Not usually with PIPE, but with SEARCH and DIFFERENCE commands and
related hackery. This is ugly, home-grown, fragile to start with, not
at all integrated, build-log-scanning will work.

Keeping around the compiler listings with embedded machine listings has
other advantages, too. Particularly around troubleshooting run-time
errors that might arise.

I'd have once suggested moving the Bliss and Macro32 code forward to
the newer mapping requirements, but it's unclear what might happen with
this code and this mapping and the x86-64 port, and — for many of us —
Itanium is increasingly now a stopgap as a deployment platform.
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2017-06-13 12:21:17 UTC
Permalink
Raw Message
Post by Stephen Hoffman
I'd have once suggested moving the Bliss and Macro32 code forward to
the newer mapping requirements, but it's unclear what might happen with
this code and this mapping and the x86-64 port, and — for many of us —
Itanium is increasingly now a stopgap as a deployment platform.
Well, IMACRO only knows about the mapping. You can't say:

MOVL r1,r2

where r2 and r3 are the actual Itanium names. You always get the results of the mapping to get

mov r9 = r28

As for x86, ironically, I've been writing up the draft of a white paper on how all the remaining BLISS LINKAGEs and GLOBAL REGISTERs (the only things that contain register names) and how the Macro compiler will be dealing with the source registers. One thing, I think I'll kill that BLISS message.
V***@SendSpamHere.ORG
2017-06-13 13:19:34 UTC
Permalink
Raw Message
=20
I'd have once suggested moving the Bliss and Macro32 code forward to=20
the newer mapping requirements, but it's unclear what might happen with=
=20
this code and this mapping and the x86-64 port, and =E2=80=94 for many of=
us =E2=80=94=20
Itanium is increasingly now a stopgap as a deployment platform.
=20
MOVL r1,r2
where r2 and r3 are the actual Itanium names. You always get the results o=
f the mapping to get
mov r9 =3D r28
As for x86, ironically, I've been writing up the draft of a white paper on =
how all the remaining BLISS LINKAGEs and GLOBAL REGISTERs (the only things =
that contain register names) and how the Macro compiler will be dealing wit=
h the source registers. One thing, I think I'll kill that BLISS message.
When might that paper be available for the mere mortals to read?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
John Reagan
2017-06-13 15:26:10 UTC
Permalink
Raw Message
Post by V***@SendSpamHere.ORG
When might that paper be available for the mere mortals to read?
--
I still have some more prototyping to do to make sure my caffeine-induced
ramblings can handle the interesting parts. I'd like to be able to discuss
the details by bootcamp and here for those of you that can't make it.
Loading...