Discussion:
x86 Cross Tools Kit
(too old to reply)
clair.grant@vmssoftware.com
2019-02-26 11:46:04 UTC
Permalink
Late last year we sent a message to our customers, partners, and ISVs asking if they would be interested in participating in the V9.0 EAK. If so, they replied with answers to a number of questions about their compiler, layered product, network, and cluster needs. From the responders we selected a dozen based on their needs, timing of product availability, and our capacity to support them. V9.0 is not the full operating system environment but rather enough of the system to start evaluating some applications.

As a first step, yesterday we made our initial Cross Tools Kit available to those selected. It consists of BLISS, C, and XMACRO compilers plus the linker and a few associated items. They run on any VSI OpenVMS version on Itanium. These are exactly the tools we use in our daily builds. We will have updates to the current kit contents plus other compilers as they become available, and eventually enough of an x86 system to start testing.
Jan-Erik Söderholm
2019-02-26 12:52:21 UTC
Permalink
Post by ***@vmssoftware.com
Late last year we sent a message to our customers, partners, and ISVs
asking if they would be interested in participating in the V9.0 EAK. If
so, they replied with answers to a number of questions about their
compiler, layered product, network, and cluster needs. From the
responders we selected a dozen based on their needs, timing of product
availability, and our capacity to support them. V9.0 is not the full
operating system environment but rather enough of the system to start
evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available
to those selected. It consists of BLISS, C, and XMACRO compilers plus
the linker and a few associated items. They run on any VSI OpenVMS
version on Itanium. These are exactly the tools we use in our daily
builds. We will have updates to the current kit contents plus other
compilers as they become available, and eventually enough of an x86
system to start testing.
A major step! The first availability of something x86 related out of VSI!
V***@SendSpamHere.ORG
2019-02-26 16:04:31 UTC
Permalink
Late last year we sent a message to our customers, partners, and ISVs askin=
g if they would be interested in participating in the V9.0 EAK. If so, they=
replied with answers to a number of questions about their compiler, layere=
d product, network, and cluster needs. From the responders we selected a do=
zen based on their needs, timing of product availability, and our capacity =
to support them. V9.0 is not the full operating system environment but rath=
er enough of the system to start evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available to=
those selected. It consists of BLISS, C, and XMACRO compilers plus the lin=
ker and a few associated items. They run on any VSI OpenVMS version on Itan=
ium. These are exactly the tools we use in our daily builds. We will have u=
pdates to the current kit contents plus other compilers as they become avai=
lable, and eventually enough of an x86 system to start testing.
I'd really love to see the XMACRO compiler and what it produces. Of course,
until there's an actual version of VMS for X86, it's not going to be much of
a concern to me not to have it.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
John Reagan
2019-02-26 15:42:46 UTC
Permalink
Post by V***@SendSpamHere.ORG
Late last year we sent a message to our customers, partners, and ISVs askin=
g if they would be interested in participating in the V9.0 EAK. If so, they=
replied with answers to a number of questions about their compiler, layere=
d product, network, and cluster needs. From the responders we selected a do=
zen based on their needs, timing of product availability, and our capacity =
to support them. V9.0 is not the full operating system environment but rath=
er enough of the system to start evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available to=
those selected. It consists of BLISS, C, and XMACRO compilers plus the lin=
ker and a few associated items. They run on any VSI OpenVMS version on Itan=
ium. These are exactly the tools we use in our daily builds. We will have u=
pdates to the current kit contents plus other compilers as they become avai=
lable, and eventually enough of an x86 system to start testing.
I'd really love to see the XMACRO compiler and what it produces. Of course,
until there's an actual version of VMS for X86, it's not going to be much of
a concern to me not to have it.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Correct. It is just helping us shake out any remaining compiler assertions. Until there is way to execute the code, you have no idea if all VAX instructions just turned into 'nop's or not.

For Macro, we can compile all sorts of nasty Macro-32 code (including the Macro compiler's parser itself, DCL, the shadow driver, etc. and my newest "least favorite" Macro file: LADDRIVER.MAR, the tricks it does with re-defining "." inside of macros is truly ugly).
Dave Froble
2019-02-26 18:26:25 UTC
Permalink
Post by John Reagan
Post by V***@SendSpamHere.ORG
Late last year we sent a message to our customers, partners, and ISVs askin=
g if they would be interested in participating in the V9.0 EAK. If so, they=
replied with answers to a number of questions about their compiler, layere=
d product, network, and cluster needs. From the responders we selected a do=
zen based on their needs, timing of product availability, and our capacity =
to support them. V9.0 is not the full operating system environment but rath=
er enough of the system to start evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available to=
those selected. It consists of BLISS, C, and XMACRO compilers plus the lin=
ker and a few associated items. They run on any VSI OpenVMS version on Itan=
ium. These are exactly the tools we use in our daily builds. We will have u=
pdates to the current kit contents plus other compilers as they become avai=
lable, and eventually enough of an x86 system to start testing.
I'd really love to see the XMACRO compiler and what it produces. Of course,
until there's an actual version of VMS for X86, it's not going to be much of
a concern to me not to have it.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Correct. It is just helping us shake out any remaining compiler assertions. Until there is way to execute the code, you have no idea if all VAX instructions just turned into 'nop's or not.
For Macro, we can compile all sorts of nasty Macro-32 code (including the Macro compiler's parser itself, DCL, the shadow driver, etc. and my newest "least favorite" Macro file: LADDRIVER.MAR, the tricks it does with re-defining "." inside of macros is truly ugly).
Every time you mention this type of thing John, it makes me wonder why
anyone would have ever written such code. Once we had VMS with virtual
memory, constraints on size sort of went away.

I like to think that my Macro-32 code is rather simple and straight
forward. At least I'd hoped so. Nothing fancy. Didn't see any reasons
to "get fancy".

Of course, I have an old "learning program" that works on VAX, but would
not compile on Alpha. Makes me think that I most likely did something a
bit "dodgie". Just wish I knew what.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John Reagan
2019-02-26 18:49:04 UTC
Permalink
Post by Dave Froble
Post by John Reagan
Post by V***@SendSpamHere.ORG
Late last year we sent a message to our customers, partners, and ISVs askin=
g if they would be interested in participating in the V9.0 EAK. If so, they=
replied with answers to a number of questions about their compiler, layere=
d product, network, and cluster needs. From the responders we selected a do=
zen based on their needs, timing of product availability, and our capacity =
to support them. V9.0 is not the full operating system environment but rath=
er enough of the system to start evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available to=
those selected. It consists of BLISS, C, and XMACRO compilers plus the lin=
ker and a few associated items. They run on any VSI OpenVMS version on Itan=
ium. These are exactly the tools we use in our daily builds. We will have u=
pdates to the current kit contents plus other compilers as they become avai=
lable, and eventually enough of an x86 system to start testing.
I'd really love to see the XMACRO compiler and what it produces. Of course,
until there's an actual version of VMS for X86, it's not going to be much of
a concern to me not to have it.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Correct. It is just helping us shake out any remaining compiler assertions. Until there is way to execute the code, you have no idea if all VAX instructions just turned into 'nop's or not.
For Macro, we can compile all sorts of nasty Macro-32 code (including the Macro compiler's parser itself, DCL, the shadow driver, etc. and my newest "least favorite" Macro file: LADDRIVER.MAR, the tricks it does with re-defining "." inside of macros is truly ugly).
Every time you mention this type of thing John, it makes me wonder why
anyone would have ever written such code. Once we had VMS with virtual
memory, constraints on size sort of went away.
I like to think that my Macro-32 code is rather simple and straight
forward. At least I'd hoped so. Nothing fancy. Didn't see any reasons
to "get fancy".
Of course, I have an old "learning program" that works on VAX, but would
not compile on Alpha. Makes me think that I most likely did something a
bit "dodgie". Just wish I knew what.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
In this case, the macro is used to help create CASE instruction dispatch tables using label expressions.

For everyone's "enjoyment"

.MACRO $DISPATCH, INDX,VECTOR,TYPE=W,NMODE=S^#,?MN,?MX,?S,?SS,?ZZ
SS:

.MACRO $DSP1,$DSP1_1
.IRP $DSP1_2,$DSP1_1
$DSP2 $DSP1_2
.ENDR
.ENDM $DSP1

.MACRO $DSP2,$DSP2_1,$DSP2_2
.=<$DSP2_1-MN>*2 + S
.WORD $DSP2_2-S
.ENDM $DSP2


.MACRO $BND1,$BND1_1,$BND1_2,$BND1_3
$BND2 $BND1_1,$BND1_2
.ENDM $BND1

.MACRO $BND2,$BND2_1,$BND2_2
.IIF $BND2_1,$BND2_2-., .=$BND2_2
.ENDM $BND2

.MACRO $BND $BND_1,$BND_2
.IRP $BND_3,<$BND_2>
$BND1 $BND_1,$BND_3
.ENDR
.ENDM $BND

.=0
ZZ:
$BND GT,<VECTOR>
MX:
$BND LT,<VECTOR>
MN:
.=SS

CASE'TYPE INDX,#<MN-ZZ>,NMODE'<MX-MN>
S:
.REPT MX-MN+1
.WORD <MX-MN>*2 + 2
.ENDR

.=S

$DSP1 <<VECTOR>>

.=<MX-MN>*2 + S + 2

.ENDM $DISPATCH

and a usage of

$DISPATCH CHD$L_BKT_BLK_S, TYPE=L,-
<- ; 2 pwr ; action
<3 13$>,-
<4 14$>,-
<5 15$>,-
<6 16$>,-
<7 17$>,-
<8 18$>,-
get the labels to line up with the static dispatch table (which is itself relative offsets for x86) uses a much different model describing it to GEM vs describing it to LLVM. It took me a while to get it right. It took longer to get over the nausea.
g***@rlgsc.com
2019-02-26 18:53:06 UTC
Permalink
Post by Dave Froble
Post by John Reagan
Post by V***@SendSpamHere.ORG
Late last year we sent a message to our customers, partners, and ISVs askin=
g if they would be interested in participating in the V9.0 EAK. If so, they=
replied with answers to a number of questions about their compiler, layere=
d product, network, and cluster needs. From the responders we selected a do=
zen based on their needs, timing of product availability, and our capacity =
to support them. V9.0 is not the full operating system environment but rath=
er enough of the system to start evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available to=
those selected. It consists of BLISS, C, and XMACRO compilers plus the lin=
ker and a few associated items. They run on any VSI OpenVMS version on Itan=
ium. These are exactly the tools we use in our daily builds. We will have u=
pdates to the current kit contents plus other compilers as they become avai=
lable, and eventually enough of an x86 system to start testing.
I'd really love to see the XMACRO compiler and what it produces. Of course,
until there's an actual version of VMS for X86, it's not going to be much of
a concern to me not to have it.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Correct. It is just helping us shake out any remaining compiler assertions. Until there is way to execute the code, you have no idea if all VAX instructions just turned into 'nop's or not.
For Macro, we can compile all sorts of nasty Macro-32 code (including the Macro compiler's parser itself, DCL, the shadow driver, etc. and my newest "least favorite" Macro file: LADDRIVER.MAR, the tricks it does with re-defining "." inside of macros is truly ugly).
Every time you mention this type of thing John, it makes me wonder why
anyone would have ever written such code. Once we had VMS with virtual
memory, constraints on size sort of went away.
I like to think that my Macro-32 code is rather simple and straight
forward. At least I'd hoped so. Nothing fancy. Didn't see any reasons
to "get fancy".
Of course, I have an old "learning program" that works on VAX, but would
not compile on Alpha. Makes me think that I most likely did something a
bit "dodgie". Just wish I knew what.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
David,

Since John did not include the code sample from LADDRIVER, one can only speculate.

However, assembler macros frequently use less common parts of the macro syntax, including sophisticated uses of "." when defining data structures. They often bounce from psect to psect, and other somewhat esoteric uses of the macro language.

Similar things happen with the LINKER. There are features in the LINKER which are needed to build certain systems programs (e.g., kernels, drivers, ACPs). While they require disproportionate effort to implement, they are vital to building a runnable system.

Perfectly legal, but not things average programmers code daily. It can be harder than it looks at first glance.

- Bob Gezelter, http://www.rlgsc.com
Arne Vajhøj
2019-02-26 19:39:16 UTC
Permalink
Post by Dave Froble
Post by John Reagan
For Macro, we can compile all sorts of nasty Macro-32 code (including
the Macro compiler's parser itself, DCL, the shadow driver, etc. and
my newest "least favorite" Macro file: LADDRIVER.MAR, the tricks it
does with re-defining "." inside of macros is truly ugly).
Every time you mention this type of thing John, it makes me wonder why
anyone would have ever written such code.  Once we had VMS with virtual
memory, constraints on size sort of went away.
Only sort of.

Yes - VMS VAX had 2 GB of P0+P1, but many old VAX'es has relative little
RAM and as was said back then "rotating memory is slow".
Post by Dave Froble
I like to think that my Macro-32 code is rather simple and straight
forward.  At least I'd hoped so.  Nothing fancy.  Didn't see any reasons
to "get fancy".
Seen in todays perspective you did it right and those writing the
code John is struggling with did it wrong.

But if we turn back time 35-40 years, then it was a different world.

The authors may not have been thinking their code would live that long.
They probably did not think Macro-32 would end up as a compiler on 3
different platforms.

The authors may have been writing Macro-32 full time in which case
they really knew this stuff well and may not have considered the
possibility that a non-dedicated Macro-32 developer would ever
have to look at the code.

Arne
Dave Froble
2019-02-26 19:52:18 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by John Reagan
For Macro, we can compile all sorts of nasty Macro-32 code (including
the Macro compiler's parser itself, DCL, the shadow driver, etc. and
my newest "least favorite" Macro file: LADDRIVER.MAR, the tricks it
does with re-defining "." inside of macros is truly ugly).
Every time you mention this type of thing John, it makes me wonder why
anyone would have ever written such code. Once we had VMS with
virtual memory, constraints on size sort of went away.
Only sort of.
Yes - VMS VAX had 2 GB of P0+P1, but many old VAX'es has relative little
RAM and as was said back then "rotating memory is slow".
Post by Dave Froble
I like to think that my Macro-32 code is rather simple and straight
forward. At least I'd hoped so. Nothing fancy. Didn't see any
reasons to "get fancy".
Seen in todays perspective you did it right and those writing the
code John is struggling with did it wrong.
But if we turn back time 35-40 years, then it was a different world.
The authors may not have been thinking their code would live that long.
They probably did not think Macro-32 would end up as a compiler on 3
different platforms.
The authors may have been writing Macro-32 full time in which case
they really knew this stuff well and may not have considered the
possibility that a non-dedicated Macro-32 developer would ever
have to look at the code.
Arne
I will admit, I've never cared for "clever programmers". Too many times
their "clever" turns out to be a problem.

Computers are not clever. They are fast. Give them simple
instructions, and they will blaze through them. Give them "clever" and
they can get confused.

I've also noticed that "clever programmers" all too often avoid the use
of comments. What use do such as they have for mere comments.

Ok, I've used macros. But not clever macros.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2019-02-26 20:22:37 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by John Reagan
For Macro, we can compile all sorts of nasty Macro-32 code (including
the Macro compiler's parser itself, DCL, the shadow driver, etc. and
my newest "least favorite" Macro file: LADDRIVER.MAR, the tricks it
does with re-defining "." inside of macros is truly ugly).
Every time you mention this type of thing John, it makes me wonder why
anyone would have ever written such code.  Once we had VMS with
virtual memory, constraints on size sort of went away.
Only sort of.
Yes - VMS VAX had 2 GB of P0+P1, but many old VAX'es has relative little
RAM and as was said back then "rotating memory is slow".
Post by Dave Froble
I like to think that my Macro-32 code is rather simple and straight
forward.  At least I'd hoped so.  Nothing fancy.  Didn't see any
reasons to "get fancy".
Seen in todays perspective you did it right and those writing the
code John is struggling with did it wrong.
But if we turn back time 35-40 years, then it was a different world.
The authors may not have been thinking their code would live that long.
They probably did not think Macro-32 would end up as a compiler on 3
different platforms.
The authors may have been writing Macro-32 full time in which case
they really knew this stuff well and may not have considered the
possibility that a non-dedicated Macro-32 developer would ever
have to look at the code.
I will admit, I've never cared for "clever programmers".  Too many times
their "clever" turns out to be a problem.
I completely agree.
Computers are not clever.  They are fast.  Give them simple
instructions, and they will blaze through them.  Give them "clever" and
they can get confused.
I would say that clever code may confuse the "clever" author himself.
I've also noticed that "clever programmers" all too often avoid the use
of comments.  What use do such as they have for mere comments.
So true.

Arne
George Cornelius
2019-02-27 05:01:00 UTC
Permalink
Post by Dave Froble
I will admit, I've never cared for "clever programmers". Too many times
their "clever" turns out to be a problem.
What you are seeing is code written by professionals. Not perfect,
but perhaps necessary given the need to provide tools to the
customer that (a) meet the specifications and (b) give the
_customer_ the least risk of shooting himself in the foot.

Yes, these are clever people. But the job demands this.
Post by Dave Froble
Computers are not clever. They are fast. Give them simple
instructions, and they will blaze through them. Give them "clever" and
they can get confused.
The computers will of course do as they are told.

If the person coding the macro is not clever enough to do it
right, then he's outsmarting himself. Or just "showing off."
Post by Dave Froble
I've also noticed that "clever programmers" all too often avoid the use
of comments. What use do such as they have for mere comments.
Different issue. But in the punched card days, comments
inserted up front might deviate significantly from the
final reality at the time coding and debugging is completed,
and heaven help you after a number of people have touched
the code to repair and improve it. Some have hoped for
so-called self-documenting code (Cobol had that goal), but
of course it was mostly an illusion that writing out
A = B * C in a natural language form might really improve
things.

Nowadays, when bits are cheap, we may actually go back
and pull out the flawed comments and insert appropriate
ones. Maybe. But some don't.
Post by Dave Froble
Ok, I've used macros. But not clever macros.
Every time you use a system service macro you invoke
some rather clever macro code that has, over the years,
been very effective at getting the job done while
staying out of the customer's way.

I will mention that in a sense a macro itself is a sort
of optimizer. If you wrote the same code as a general-
purpose subroutine, it would have to have conditionals
to handle all the cases the customer might throw at it,
and that would be duly compiled and would result in
perhaps a significant amount of code that would not be
needed, while some of the code that would be used would
be extraneous in that the customer's invocation of it
would always be taking the same path through the
conditionals.

Macros tend to be designed to generate only the code
that is needed for the supplied arguments. The
conditionals for excluding code are assembly time
only and are not present at all in the object code.
Not that the macro actually generates optimal code -
generally you only put limited effort into achieving
that end - but it generates code that is appropriate
to the specifics of the invocation.

Pardon the rant, but the first programming language
I learned was IBM 1440 Autocoder (assembler), and
I was amazed, first, that there might be computers
that could neither multiply nor divide, and, second,
that there were such things as multiply macros,
with a dozen or more arguments and a penchant for
generating pages of code to perform the necessary
decimal shifts and adds while making adjustmens for
implied decimal points and rounding and who knows
what else. And if multiply was difficult, divide
was of course another level more convoluted than
that.

George
Post by Dave Froble
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2019-02-27 14:26:55 UTC
Permalink
Post by George Cornelius
Post by Dave Froble
I will admit, I've never cared for "clever programmers". Too many times
their "clever" turns out to be a problem.
What you are seeing is code written by professionals. Not perfect,
but perhaps necessary given the need to provide tools to the
customer that (a) meet the specifications and (b) give the
_customer_ the least risk of shooting himself in the foot.
Yes, these are clever people. But the job demands this.
Post by Dave Froble
Computers are not clever. They are fast. Give them simple
instructions, and they will blaze through them. Give them "clever" and
they can get confused.
The computers will of course do as they are told.
If the person coding the macro is not clever enough to do it
right, then he's outsmarting himself. Or just "showing off."
I think there are different opinions about what
professional means.

Using the most advanced features in the "language" (quotation
marks due to this being Macro-32) to provide a solution with
fewest lines of code, least memory usage and fastest execution
time is in most cases even when perfectly implemented
amateurish.

In the typical case professional means creating some code
that meet minimum requirements and are so simple that
all the maintenance programmers having to maintain it for
the next 10-40 years can easily understand it.

A couple of well known quotes that are sort of related:

"More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity."

"Programmers waste enormous amounts of time thinking about, or worrying
about, the speed of noncritical parts of their programs, and these
attempts at efficiency actually have a strong negative impact when
debugging and maintenance are considered. We should forget about small
efficiencies, say about 97% of the time: premature optimization is the
root of all evil. Yet we should not pass up our opportunities in that
critical 3%."

"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live."

Arne
g***@rlgsc.com
2019-02-26 20:36:26 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by John Reagan
For Macro, we can compile all sorts of nasty Macro-32 code (including
the Macro compiler's parser itself, DCL, the shadow driver, etc. and
my newest "least favorite" Macro file: LADDRIVER.MAR, the tricks it
does with re-defining "." inside of macros is truly ugly).
Every time you mention this type of thing John, it makes me wonder why
anyone would have ever written such code.  Once we had VMS with virtual
memory, constraints on size sort of went away.
Only sort of.
Yes - VMS VAX had 2 GB of P0+P1, but many old VAX'es has relative little
RAM and as was said back then "rotating memory is slow".
Post by Dave Froble
I like to think that my Macro-32 code is rather simple and straight
forward.  At least I'd hoped so.  Nothing fancy.  Didn't see any reasons
to "get fancy".
Seen in todays perspective you did it right and those writing the
code John is struggling with did it wrong.
But if we turn back time 35-40 years, then it was a different world.
The authors may not have been thinking their code would live that long.
They probably did not think Macro-32 would end up as a compiler on 3
different platforms.
The authors may have been writing Macro-32 full time in which case
they really knew this stuff well and may not have considered the
possibility that a non-dedicated Macro-32 developer would ever
have to look at the code.
Arne
Arne,

With all due respect, I disagree.

The case that John posted is along the lines that I expected. When building dispatch tables, it was (and is) common practice to define the default behavior, then back fill entries that are non-default. Redefining the assembler location pointer is the way that this must be done.

The macro assembler was designed to be used in this way. Macro-32 is no different than Macro-11. For that matter, IBM System/360 allowed (and needed) the same techniques.

While this example was apparently in normal code, the most aggressive use of the macro language was typically in the automatically generated file for building the system data structures (True for both OS/360 and RSX-11M/S).

One can also find advanced macros in the I/O data structure macros, where it is sometimes necessary to define constant pools out of line with the actual data structure.

- Bob Gezelter, http://www.rlgsc.com
Simon Clubley
2019-02-26 21:26:03 UTC
Permalink
Post by g***@rlgsc.com
The case that John posted is along the lines that I expected. When
building dispatch tables, it was (and is) common practice to define the
default behavior, then back fill entries that are non-default. Redefining
the assembler location pointer is the way that this must be done.
Maybe so, but whoever wrote the macro John posted has just lost the
right to say that C is hard to read. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
V***@SendSpamHere.ORG
2019-02-27 00:04:47 UTC
Permalink
Post by Simon Clubley
Post by g***@rlgsc.com
The case that John posted is along the lines that I expected. When
building dispatch tables, it was (and is) common practice to define the
default behavior, then back fill entries that are non-default. Redefining
the assembler location pointer is the way that this must be done.
Maybe so, but whoever wrote the macro John posted has just lost the
right to say that C is hard to read. :-)
Meh!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Forster, Michael
2019-02-26 23:32:14 UTC
Permalink
Truly awesome news!

I don't know how long I'll be able to stay on VMS due to Intersystems cache database and their VAR developers and major application vendor abandonment of VMS.

Actually I don't know how long as a non MS Windows focused or lifetime person, I would be able to stay or remain anywhere as a technician.

Michael Forster
Enterprise Storage and IDX Architect | Information Services
Medical College of Wisconsin
O: (414) 955-4967 | ***@mcw.edu


________________________________________
From: Info-vax <info-vax-***@rbnsn.com> on behalf of clair.grant--- via Info-vax <info-***@rbnsn.com>
Sent: Tuesday, February 26, 2019 5:46:04 AM
To: info-***@rbnsn.com
Cc: ***@vmssoftware.com
Subject: [Info-vax] x86 Cross Tools Kit

ATTENTION: This email originated from a sender outside of MCW. Use caution when clicking on links or opening attachments.
________________________________

Late last year we sent a message to our customers, partners, and ISVs asking if they would be interested in participating in the V9.0 EAK. If so, they replied with answers to a number of questions about their compiler, layered product, network, and cluster needs. From the responders we selected a dozen based on their needs, timing of product availability, and our capacity to support them. V9.0 is not the full operating system environment but rather enough of the system to start evaluating some applications.

As a first step, yesterday we made our initial Cross Tools Kit available to those selected. It consists of BLISS, C, and XMACRO compilers plus the linker and a few associated items. They run on any VSI OpenVMS version on Itanium. These are exactly the tools we use in our daily builds. We will have updates to the current kit contents plus other compilers as they become available, and eventually enough of an x86 system to start testing.
a***@yahoo.com
2019-02-27 11:06:17 UTC
Permalink
Post by ***@vmssoftware.com
Late last year we sent a message to our customers, partners, and ISVs asking if they would be interested in participating in the V9.0 EAK. If so, they replied with answers to a number of questions about their compiler, layered product, network, and cluster needs. From the responders we selected a dozen based on their needs, timing of product availability, and our capacity to support them. V9.0 is not the full operating system environment but rather enough of the system to start evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available to those selected. It consists of BLISS, C, and XMACRO compilers plus the linker and a few associated items. They run on any VSI OpenVMS version on Itanium. These are exactly the tools we use in our daily builds. We will have updates to the current kit contents plus other compilers as they become available, and eventually enough of an x86 system to start testing.
IMHO, you are moving in the wrong direction.
What you really should do is a release of cross-development tools that are hosted on different x86-64 OSes (probably prioritizing Linux and Windows over Mac OS/X and *BSDs) rather than on non-x86 OVMS platforms.
Jan-Erik Söderholm
2019-02-27 11:54:17 UTC
Permalink
On Tuesday, February 26, 2019 at 1:46:06 PM UTC+2,
Post by ***@vmssoftware.com
Late last year we sent a message to our customers, partners, and ISVs
asking if they would be interested in participating in the V9.0 EAK.
If so, they replied with answers to a number of questions about their
compiler, layered product, network, and cluster needs. From the
responders we selected a dozen based on their needs, timing of product
availability, and our capacity to support them. V9.0 is not the full
operating system environment but rather enough of the system to start
evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit
available to those selected. It consists of BLISS, C, and XMACRO
compilers plus the linker and a few associated items. They run on any
VSI OpenVMS version on Itanium. These are exactly the tools we use in
our daily builds. We will have updates to the current kit contents
plus other compilers as they become available, and eventually enough
of an x86 system to start testing.
IMHO, you are moving in the wrong direction. What you really should do
is a release of cross-development tools that are hosted on different
x86-64 OSes (probably prioritizing Linux and Windows over Mac OS/X and
*BSDs) rather than on non-x86 OVMS platforms.
Maybe VSI is are moving in the only available and practical direction.

The fact that VSI *is* moving at all, is enough for me. And I'm sure that
there will be tools on x86-64 in due time. For now, the larger sites that
are part of the evaluation probably have access to IA64 systems.
g***@rlgsc.com
2019-02-27 13:21:30 UTC
Permalink
Post by a***@yahoo.com
Post by ***@vmssoftware.com
Late last year we sent a message to our customers, partners, and ISVs asking if they would be interested in participating in the V9.0 EAK. If so, they replied with answers to a number of questions about their compiler, layered product, network, and cluster needs. From the responders we selected a dozen based on their needs, timing of product availability, and our capacity to support them. V9.0 is not the full operating system environment but rather enough of the system to start evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available to those selected. It consists of BLISS, C, and XMACRO compilers plus the linker and a few associated items. They run on any VSI OpenVMS version on Itanium. These are exactly the tools we use in our daily builds. We will have updates to the current kit contents plus other compilers as they become available, and eventually enough of an x86 system to start testing.
IMHO, you are moving in the wrong direction.
What you really should do is a release of cross-development tools that are hosted on different x86-64 OSes (probably prioritizing Linux and Windows over Mac OS/X and *BSDs) rather than on non-x86 OVMS platforms.
Already,

Clearly, the purpose of the "cross" tools is for preparing to port applications on OpenVMS to x86-64. In essence, VSI is releasing the versions of the tools that they are using in the process of porting the OpenVMS source pool to x86-64. It is not unreasonable to presume that those with applications on OpenVMS have access to an OpenVMS system.

What is the notional niche for cross-development tools on non-OpenVMS systems? The clear answer would seem to evangelism, but at this point that does not make a lot of sense. At release, a far better alternative would be to pre-package a system image(s) for use with one or more of the virtual machine offerings for those who are new to OpenVMS.

- Bob Gezelter, http://www.rlgsc.com
John Reagan
2019-02-27 13:36:50 UTC
Permalink
Post by a***@yahoo.com
Post by ***@vmssoftware.com
Late last year we sent a message to our customers, partners, and ISVs asking if they would be interested in participating in the V9.0 EAK. If so, they replied with answers to a number of questions about their compiler, layered product, network, and cluster needs. From the responders we selected a dozen based on their needs, timing of product availability, and our capacity to support them. V9.0 is not the full operating system environment but rather enough of the system to start evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available to those selected. It consists of BLISS, C, and XMACRO compilers plus the linker and a few associated items. They run on any VSI OpenVMS version on Itanium. These are exactly the tools we use in our daily builds. We will have updates to the current kit contents plus other compilers as they become available, and eventually enough of an x86 system to start testing.
IMHO, you are moving in the wrong direction.
What you really should do is a release of cross-development tools that are hosted on different x86-64 OSes (probably prioritizing Linux and Windows over Mac OS/X and *BSDs) rather than on non-x86 OVMS platforms.
As Bob mentioned, what purpose other than novelty would a Linux-hosted Macro-32 compiler or Linux-hosted BLISS compiler (which did exist in the past) serve? There's not a lot of open-source BLISS code just waiting to be compiled.

The Macro compiler is written in Macro/BLISS/C. The BLISS compiler is written in BLISS. In order to produce a Linux-x86-hosted compiler, We'd still need to use a cross-compiler somewhere, right? We'd have to create the Itanium-hosted, x86-target cross-compilers to start that journey. And that code is chocked-full of OpenVMS'isms and system calls. The compilers want to use FAB/RAB/$OPEN to process files, process their DCL command lines, etc. Not rocket science to map to some abstraction. That is exactly what GEM provides for frontends to use, but the other tools (linker, librarian, etc) are not setup for an abstraction.

Since the OS build is heavily dependent on the VDE tool, DCL command files, other tools (linker, librarian, message, CDU, etc), moving the OS build over to Linux is a heavy lift which would just slow down any porting effort. [We did discuss this option in the beginning.]
Dave Froble
2019-02-27 15:05:51 UTC
Permalink
Post by a***@yahoo.com
Post by ***@vmssoftware.com
Late last year we sent a message to our customers, partners, and ISVs asking if they would be interested in participating in the V9.0 EAK. If so, they replied with answers to a number of questions about their compiler, layered product, network, and cluster needs. From the responders we selected a dozen based on their needs, timing of product availability, and our capacity to support them. V9.0 is not the full operating system environment but rather enough of the system to start evaluating some applications.
As a first step, yesterday we made our initial Cross Tools Kit available to those selected. It consists of BLISS, C, and XMACRO compilers plus the linker and a few associated items. They run on any VSI OpenVMS version on Itanium. These are exactly the tools we use in our daily builds. We will have updates to the current kit contents plus other compilers as they become available, and eventually enough of an x86 system to start testing.
IMHO, you are moving in the wrong direction.
What you really should do is a release of cross-development tools that are hosted on different x86-64 OSes (probably prioritizing Linux and Windows over Mac OS/X and *BSDs) rather than on non-x86 OVMS platforms.
So, you want them to start all over again ??

How many years of work do you want them to toss ??

All for something that that won't matter once VMS is running on x86 ??
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2019-02-27 16:45:10 UTC
Permalink
Post by a***@yahoo.com
IMHO, you are moving in the wrong direction.
What you really should do is a release of cross-development tools that
are hosted on different x86-64 OSes (probably prioritizing Linux and
Windows over Mac OS/X and *BSDs) rather than on non-x86 OVMS platforms.
The VSI folks are trying to get the base operating system going on
x86-64, and cross-platform *and* cross-operating system tooling is a
much more difficult and unnecessary complication here.

The end-goal of these specific cross-tools tools is replacement with
native tools, once the native tools are available.

Which will be happening once the OpenVMS x86-64 platform boots and work
progresses to be able to build the native tools natively. Until then,
the cross tools are necessary.

This current approach closely mirrors what was done during the port
from Alpha to Itanium, too.

Then maybe somebody looks at these cross-tools as some part of the
foundation for cross-platform development if not remote compilation,
though that cross-platform work is probably only going to be available
five or ten years in the future at the earliest.

The most recent roadmap had a mention of IDE support; Visual Studio Code.
https://vmssoftware.com/pdfs/VSI_Roadmap_20190121.pdf

Oh, and the cross-tools back during the Itanium port—when the
cross-tools were all working correctly—could be "fun" to sort out the
compilation host architecture and the target architecture and variant
builds in the source code being compiled and linked. There's a lot of
code around that uses architecture-specific conditional compilation,
and any cross-platform tools and any IDE will have to sort all that
out. And preferably without requiring source code changes specific to
cross-tool processing. But that's all fodder for a different
discussion.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...