Macro VAX to Alpha porting question

[Tom Adams]

I was trying to revise a macro routine and found that it had not been
properly ported from VAX to ALPHA.

I get the MAXARGUSE and ARGLISHOME informationals. We overlooked them
in the port long ago, these informationals were actually reporting
bugs. (Fortunately, the bugs were latent.)

Anyway, I think I need to replace the .entry directive:

.entry pcs_trcbck, ^m<r4>

with the proper call_entry directive, since the automatic conversion
is not sufficient.

This is my first guess for the replacement:

START:: .CALL_ENTRY MAX_ARGS=15,HOME_ARGS=TRUE

This compiles OK, but I am not sure it's correct. I set max_args=15
because I think that actually causes a runtime determination of the
maximum. The routine has a variable length argument list.

My main concern is that I don't know what "^m<r4>" means, do I need to
add something to the .call_macro directive to cover that?

Any other issues?

Thanks in advance. I am having problems finding answers in my web
searches.

[abrsvc]

The ^M<R4> is the register save mask and indictes to save/restore R4.

The max args you specified should be ok.

If you'd like, send me a copy of the routine and its caller. I can verify the code and get back to you. Email me at dansabrservices AT yahoo

Dan

[Tom Adams]

It's not working correctly

This call to the routine:

call pcs_trcbck('foobar',mc$pcs_foobar,%val(4),%val(1),%val(2),
%val(3),%val(4))

is suppose to do the same as this:

call lib$signal(mc$pcs_trcbck,%val(2),prc_getnam(),'foobar',mc
$pcs_foobar,%val(4),%val(1),%val(2),%val(3),%val(4))

but it only works correctly if pcs_trcbck has less than 6 arguments!

Here is the whole routine:

.title pcs_trcbck
.ident /01/

; Function

;F The PCS_TRCBCK procedure calls LIB$SIGNAL using arguments
;F passed on the argument stack.

; Inputs

;I*.len;

; Outputs

;O*.len;

; Design Considerations

;D The PCS_TRCBCK procedure is written in VAX-11 Macro in order
;D to allow the routine to accept a variable length argument
list.

.psect data

prcnam: .ascid / /
namlng: .blkl

.psect code

.CALL_ENTRY LABEL=XXX,MAX_ARGS=15,HOME_ARGS=TRUE

pushal namlng ;Put buffer length on
stack
pushal prcnam ;Put name buffer on
stack
calls #2, prc_getnam ;Get process name

movzbl (ap), r4 ;Get number of
arguments

10$: pushl (ap)[r4] ;Place arguments on
stack
sobgtr r4, 10$

pushal prcnam ;Save process name
pushl #2 ;Traceback error
arguments
pushl #mc$pcs_trcbck ;Traceback error

movzbl (ap), r4 ;Number of arguments
addl #3, r4 ;Traceback error
arguments
calls r4, g^lib$signal ;Signal error

movl #ss$_normal, r0 ;Set return status

ret
.end

[Tom Adams]

Correction. It works for 6 arguments, but not more than 6
arguments. It puts out zeros or incorrect values for any argument
past 6.

[Stephen Hoffman]

On 2013-05-15 13:46:35 +0000, Tom Adams said:

> I was trying to revise a macro routine and found that it had not been
> properly ported from VAX to ALPHA.

> ....

> Any other issues?
>
> Thanks in advance. I am having problems finding answers in my web searches.

There is documentation available on the topic of porting Macro32
assembler to the OpenVMS Alpha and OpenVMS I64 Macro32 compilers.

This documentation is available in HTML and PDF formats:

<http://h71000.www7.hp.com/doc/82final/5601/5601pro.html>
<http://h71000.www7.hp.com/doc/82final/5601/aa-pv64e-te.pdf>

These materials are part of the primary documentation for OpenVMS,
available here:

<http://www.hp.com/go/openvms/doc>

There are additional materials on porting (more generic) applications
to 64-bit OpenVMS available in the OpenVMS documentation set, as well.

You'll also find older OpenVMS documentation in an archive, and this
archive includes materials on porting applications and device drivers.

Look here for the archives:

<http://h71000.www7.hp.com/doc/archived.html>

In various cases, I've found it more effective to replace the legacy
Macro32 code with newer routines written in some other higher-level
language, as various old Macro32 code can predate the availability of
newer language calls, RTL calls and system services. In some cases,
the entire existence of the Macro32 code was to work around some gap in
the then-current VMS features, and that could be replaced with a few
(different) calls in whatever was calling the Macro32 code.

--
Pure Personal Opinion | HoffmanLabs LLC

[Stephen Hoffman]

On 2013-05-15 15:41:38 +0000, Tom Adams said:

> On May 15, 10:08�am, abrsvc <dansabrservi...@yahoo.com> wrote:
>> The ^M<R4> is the register save mask and indictes to save/restore R4.
>>
>> The max args you specified should be ok.
>>
>> If you'd like, send me a copy of the routine and its caller. �I can
>> verify the code and get back to you. �Email me at dansabrservices �AT
>> yahoo
>>
>> Dan
> It's not working correctly

Specific error messages or details would help.

>
> This call to the routine:
>
> call pcs_trcbck('foobar',mc$pcs_foobar,%val(4),%val(1),%val(2),
> %val(3),%val(4))
>
> is suppose to do the same as this:
>
> call lib$signal(mc$pcs_trcbck,%val(2),prc_getnam(),'foobar',mc
> $pcs_foobar,%val(4),%val(1),%val(2),%val(3),%val(4))

You can use lib$callg() for this. C, too, can happily call whatever.

> but it only works correctly if pcs_trcbck has less than 6 arguments!

The first six arguments are passed by register on Alpha, unless the
call is "homed".

> Here is the whole routine:
>
> .title pcs_trcbck
> .ident /01/
>
> ; Function
>
> ;F The PCS_TRCBCK procedure calls LIB$SIGNAL using arguments
> ;F passed on the argument stack.

....

> ;D The PCS_TRCBCK procedure is written in VAX-11 Macro in order
> ;D to allow the routine to accept a variable length argument list.

Stuff that knows and uses the details of the VAX calling standard will
usually have to be reworked or rewritten.

This stuff does need work.

See the porting documentation I referenced earlier.

Also see the OpenVMS Calling Standard documentation.

<http://h71000.www7.hp.com/doc/82final/5973/aa-qsbbe-te.pdf>
<http://h71000.www7.hp.com/doc/82final/5973/5973pro.html>

Depending on how intimately this code uses the calling standard and
signal handling, you may eventually need to rework this stuff if
(when?) porting to Itanium, too.

For this particular case, replace this pcs_trcbck() stuff with a call
to lib$callg() would be easy, or with a jacket written in C or C++ or
most pointer-capable languages. (C can call with variable-numbers of
arguments and that's particularly handy with some of the C99 variadic
macro features (which do exist in the VMS C compilers), but other
languages can lack that capability.)

<http://h71000.www7.hp.com/doc/82final/5932/5932pro_003.html#callg>

[Tom Adams]

On May 15, 1:37 pm, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
wrote:

Rewriting pcs_trcbck in C is a great idea!

We already have C in our system, so we have the C complier.

I think that's the fix!

You correct surmised that the only reason we have this macro in the
system is for the variable length argument list.

Thanks!

[Tom Adams]

I looked at the syntax for processing a variable length argument list
in C.

The only way to do it that I can think of is to have a case structure
with a bunch of LIB$SIGNAL calls with arguments list from size 1 to N.

It there a cleaner way?

[Stephen Hoffman]

On 2013-05-15 19:30:08 +0000, Tom Adams said:

> It there a cleaner way?

[VAXman-]

In article <7d84b7ec-c9cc-45ed...@e13g2000yqp.googlegroups.com>, Tom Adams <w.tom...@gmail.com> writes:

>On May 15, 10:08=A0am, abrsvc <dansabrservi...@yahoo.com> wrote:
>> The ^M<R4> is the register save mask and indictes to save/restore R4.
>>
>> The max args you specified should be ok.
>>

>> If you'd like, send me a copy of the routine and its caller. =A0I can ver=
>ify the code and get back to you. =A0Email me at dansabrservices =A0AT yaho=

>o
>>
>> Dan
>It's not working correctly
>
>This call to the routine:
>
> call pcs_trcbck('foobar',mc$pcs_foobar,%val(4),%val(1),%val(2),
>%val(3),%val(4))
>
>is suppose to do the same as this:
>
> call lib$signal(mc$pcs_trcbck,%val(2),prc_getnam(),'foobar',mc
>$pcs_foobar,%val(4),%val(1),%val(2),%val(3),%val(4))
>
>but it only works correctly if pcs_trcbck has less than 6 arguments!
>
>Here is the whole routine:
>
> .title pcs_trcbck
> .ident /01/
>
>; Function
>
>;F The PCS_TRCBCK procedure calls LIB$SIGNAL using arguments
>;F passed on the argument stack.
>
>; Inputs
>
>;I*.len;
>
>; Outputs
>
>;O*.len;
>
>; Design Considerations
>
>;D The PCS_TRCBCK procedure is written in VAX-11 Macro in order
>;D to allow the routine to accept a variable length argument
>list.
>

>..psect data

>
>prcnam: .ascid / /
>namlng: .blkl
>

>..psect code
>
> .CALL_ENTRY LABEL=3DXXX,MAX_ARGS=3D15,HOME_ARGS=3DTRUE

>
> pushal namlng ;Put buffer length on
>stack
> pushal prcnam ;Put name buffer on
>stack
> calls #2, prc_getnam ;Get process name
>
> movzbl (ap), r4 ;Get number of
>arguments
>
>10$: pushl (ap)[r4] ;Place arguments on
>stack
> sobgtr r4, 10$
>
> pushal prcnam ;Save process name
> pushl #2 ;Traceback error
>arguments
> pushl #mc$pcs_trcbck ;Traceback error
>
> movzbl (ap), r4 ;Number of arguments
> addl #3, r4 ;Traceback error
>arguments
> calls r4, g^lib$signal ;Signal error
>
> movl #ss$_normal, r0 ;Set return status
>
> ret
> .end

You should receive a dose of high-velocity lead poisoning for writing such
ugly Macro!


--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[Stephen Hoffman]

On 2013-05-15 19:30:08 +0000, Tom Adams said:

> I looked at the syntax for processing a variable length argument list in C.
>
> The only way to do it that I can think of is to have a case structure
> with a bunch of LIB$SIGNAL calls with arguments list from size 1 to N.
>
> It there a cleaner way?

There are also TBK$ traceback calls around, depending on what you're up
to with that code.

<http://labs.hoffmanlabs.com/node/800> has both an intro to the ACCVIO,
and links to the callable traceback stuff.

Or invoke the debugger at run-time
<http://labs.hoffmanlabs.com/node/848>, and use that to go poking
around in the code.

[John Reagan]

> "Tom Adams" wrote in message
> news:7d84b7ec-c9cc-45ed...@e13g2000yqp.googlegroups.com...

Negative Macro-32 comments aside, here are my comments:

> .psect data

> prcnam: .ascid / /
> namlng: .blkl

> .psect code

> .CALL_ENTRY LABEL=XXX,MAX_ARGS=15,HOME_ARGS=TRUE

> pushal namlng ;Put buffer length on
> stack
> pushal prcnam ;Put name buffer on stack
> calls #2, prc_getnam ;Get process name

This pushes the address of the 32-bit namlng variable (INTEGER*4 since you
seem to be using Fortran along with the Macro-32). And it pushes the
address of a descriptor which describes 'prcnam'. It isn't pushing the
address of buffer but the address of the descriptor to the buffer. Is that
intentional? Is 'prc_getnam' in Fortran?

> pushal prcnam ;Save process name

Again, this pushes the address of the descriptor to the name. How is the
mc$pcs_trckbck error string defined in the .msg file? What FAO codes are
used? Did 'prc_getnam' update the passed descriptor?

There isn't anything wrong with using Macro-32 to copy over the argument
list, add 3 more arguments to it, and then call LIB$SIGNAL. That is done
several times inside of the OpenVMS code base itself.

If you can give more info, I'm happy to help. Of course giving up and
rewriting it will avoid whatever problem you have now.

John

[VAXman-]

In article <kJKdnQmywooKsQnM...@insightbb.com>, "John Reagan" <johnr...@earthlink.net> writes:
>
>
>> "Tom Adams" wrote in message
>> news:7d84b7ec-c9cc-45ed...@e13g2000yqp.googlegroups.com...
>
>Negative Macro-32 comments aside, here are my comments:
>
>
>> .psect data
>
>> prcnam: .ascid / /
>> namlng: .blkl
>
>> .psect code
>
>> .CALL_ENTRY LABEL=XXX,MAX_ARGS=15,HOME_ARGS=TRUE
>
>> pushal namlng ;Put buffer length on
>> stack
>> pushal prcnam ;Put name buffer on stack
>> calls #2, prc_getnam ;Get process name
>
>This pushes the address of the 32-bit namlng variable (INTEGER*4 since you
>seem to be using Fortran along with the Macro-32). And it pushes the
>address of a descriptor which describes 'prcnam'. It isn't pushing the
>address of buffer but the address of the descriptor to the buffer. Is that
>intentional? Is 'prc_getnam' in Fortran?
>
>
>> pushal prcnam ;Save process name
>
>Again, this pushes the address of the descriptor to the name. How is the
>mc$pcs_trckbck error string defined in the .msg file? What FAO codes are
>used? Did 'prc_getnam' update the passed descriptor?

Knowing that would help. This code isn't very AST-reentrant either
with that data .psect holding the prcnam.

>There isn't anything wrong with using Macro-32 to copy over the argument
>list, add 3 more arguments to it, and then call LIB$SIGNAL. That is done
>several times inside of the OpenVMS code base itself.

:)

>If you can give more info, I'm happy to help. Of course giving up and
>rewriting it will avoid whatever problem you have now.

Will it?

[John Reagan]

wrote in message news:00AD3537...@SendSpamHere.ORG...

>>If you can give more info, I'm happy to help. Of course giving up and
>>rewriting it will avoid whatever problem you have now.

> Will it?

In exchange for another unknown set of problems? Yep.

Recoding into C is much like shuffling the deck chairs on the Titanic.
Distracts you from the real problem, and by the time you realize it, you are
out of time and totally sunk.

On the other hand, recoding into C (or recoding to any other language) can
often expose bugs since it forces you to think about that the Macro-32 is
actually doing. Of course, that assumes you knew what it did in the first
place.

John (who does have just a little experience with Macro-32 and the Macro-32
compiler)

[VAXman-]

In article <N8WdnWFp3_uO0gnM...@insightbb.com>, "John Reagan" <johnr...@earthlink.net> writes:
>
>
>wrote in message news:00AD3537...@SendSpamHere.ORG...
>
>
>>>If you can give more info, I'm happy to help. Of course giving up and
>>>rewriting it will avoid whatever problem you have now.
>
>> Will it?
>
>In exchange for another unknown set of problems? Yep.
>
>Recoding into C is much like shuffling the deck chairs on the Titanic.
>Distracts you from the real problem, and by the time you realize it, you are
>out of time and totally sunk.

:)

>On the other hand, recoding into C (or recoding to any other language) can
>often expose bugs since it forces you to think about that the Macro-32 is
>actually doing. Of course, that assumes you knew what it did in the first
>place.

The definition of the message and its FAo arguments would have helped with
that fugly macro that was posted.

>John (who does have just a little experience with Macro-32 and the Macro-32
>compiler)

And I thank you greatly for that little experience! ;)

[Tom Adams]

On May 16, 8:01 am, VAXman- @SendSpamHere.ORG wrote:
> In article <N8WdnWFp3_uO0gnMnZ2dnUVZ_omdn...@insightbb.com>, "John Reagan" <johnrrea...@earthlink.net> writes:
>
>
>
> >wrote in messagenews:00AD3537...@SendSpamHere.ORG...

Here is the message as defined in the message file:

trcbck <Traceback from process !AS in module !AS> /FAO=2

[Tom Adams]

On May 15, 8:56 pm, VAXman- @SendSpamHere.ORG wrote:

Seems like the advantage of rewriting in C is that it would make
future ports easier. This system is coded in a mixture of Fortran, C,
and a bit of Macro. Plus, a good bit of Datatrieve ("the horror, the
horror" - Conrad "Heart of Darkness") to load a database.

The disadvantage is that it might be quicker to fix the macro if I
only know what was wrong.

[Tom Adams]

On May 15, 11:14 pm, "John Reagan" <johnrrea...@earthlink.net> wrote:
> wrote in messagenews:00AD3537...@SendSpamHere.ORG...

Recoding into C would allow me to NOT think about what the macro is
doing!

[Tom Adams]

[Tom Adams]

On May 15, 8:46 pm, "John Reagan" <johnrrea...@earthlink.net> wrote:

prc_getnam is in FORTRAN

The code I posted still gives these informational messages: AMAC-I-
VARSIZSTK and AMAC-I-RUNTIMSTK

The orginal code with .ENTRY instead of .CALL_ENTRY gave these
additoinal informationals:

AMAC-I-ARGLISHOME and AMAC-I-MAXARGUSE

but MAXARGUSE was actually a bug indicator, since it says the the
maximum arguments of PCS_TRCBCK was set to 6

The mystery is that, even after I "fix" this by using .CALL_ENTRY,
testing indicates that it is still the case that only 6 arguments are
used.

[John Reagan]

"Tom Adams" wrote in message

news:36c224ba-76d5-411e...@b2g2000yqe.googlegroups.com...

> Seems like the advantage of rewriting in C is that it would make
> future ports easier. This system is coded in a mixture of Fortran, C,
> and a bit of Macro. Plus, a good bit of Datatrieve ("the horror, the
> horror" - Conrad "Heart of Darkness") to load a database.

Port to where? Another platform that also provides Fortran and Datatrieve?
That certainly narrows it down.

Can you post the Fortran for the prc_getnam?

[VAXman-]

In article <28a3759f-1a18-4e01...@n11g2000yqe.googlegroups.com>, Tom Adams <w.tom...@gmail.com> writes:
>On May 15, 8:46=A0pm, "John Reagan" <johnrrea...@earthlink.net> wrote:
>> > "Tom Adams" =A0wrote in message
>> >news:7d84b7ec-c9cc-45ed...@e13g2000yqp.googlegroups.com..=

>..
>>
>> Negative Macro-32 comments aside, here are my comments:
>>

>> > =A0 =A0 =A0 =A0 .psect data
>> > prcnam: .ascid =A0/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
>> > namlng: .blkl
>> > .psect code
>> > =A0 =A0 =A0 =A0 .CALL_ENTRY LABEL=3DXXX,MAX_ARGS=3D15,HOME_ARGS=3DTRUE
>> > =A0 =A0 =A0 =A0 pushal =A0namlng =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
>=A0 =A0 =A0 =A0;Put buffer length on
>> > stack
>> > =A0 =A0 =A0 =A0 pushal =A0prcnam =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
>=A0 =A0 =A0 =A0;Put name buffer on stack
>> > =A0 =A0 =A0 =A0 calls =A0 #2, prc_getnam =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
>=A0 =A0;Get process name
>>
>> This pushes the address of the 32-bit namlng variable (INTEGER*4 since yo=
>u
>> seem to be using Fortran along with the Macro-32). =A0And it pushes the
>> address of a descriptor which describes 'prcnam'. =A0It isn't pushing the
>> address of buffer but the address of the descriptor to the buffer. =A0Is =
>that
>> intentional? =A0Is 'prc_getnam' in Fortran?
>>
>> > =A0 =A0 =A0 =A0 pushal =A0prcnam =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
>=A0 =A0 =A0 =A0;Save process name
>>
>> Again, this pushes the address of the descriptor to the name. =A0How is t=
>he
>> mc$pcs_trckbck error string defined in the .msg file? =A0What FAO codes a=
>re
>> used? =A0Did 'prc_getnam' update the passed descriptor?

>>
>> There isn't anything wrong with using Macro-32 to copy over the argument

>> list, add 3 more arguments to it, and then call LIB$SIGNAL. =A0That is do=

>ne
>> several times inside of the OpenVMS code base itself.
>>

>> If you can give more info, I'm happy to help. =A0Of course giving up and

>> rewriting it will avoid whatever problem you have now.
>>
>> John
>
>prc_getnam is in FORTRAN
>
>The code I posted still gives these informational messages: AMAC-I-
>VARSIZSTK and AMAC-I-RUNTIMSTK
>
>The orginal code with .ENTRY instead of .CALL_ENTRY gave these
>additoinal informationals:
>
>AMAC-I-ARGLISHOME and AMAC-I-MAXARGUSE
>
>but MAXARGUSE was actually a bug indicator, since it says the the
>maximum arguments of PCS_TRCBCK was set to 6
>
>The mystery is that, even after I "fix" this by using .CALL_ENTRY,
>testing indicates that it is still the case that only 6 arguments are
>used.

From what you've ported to date, I've taken the liberty of coding this for
you. I'm assuming that the "PCS_PRCNAM" is getting the process name. For
this, I chose to use LIB$GETJPI. I've also removed the static storage of
the descriptor so now this should be AST-reentrant.


.TITLE PCS_TRCBCK
.IDENT /01/

TOBITS = 3 ; convert: shift for bytes to bits

.LIBRARY "SYS$LIBRARY:STARLET.MLB" ; look here for:

$DSCDEF ; OpenVMS descriptor definitions
$JPIDEF ; $GETJPI item code definitions

$LIB$ROUTINESDEF; LIB$ RTL macro definitions
$STR$ROUTINESDEF; LIB$ RTL macro definitions

.PSECT CODE,NOWRT,EXE,5

.CALL_ENTRY LABEL=PCS_TRCBCK,MAX_ARGS=15,HOME_ARGS=TRUE

;++
; Create a Dynamic String Descriptor on the stack.
; LIB$GETJPI will place the process name into this.
;--

CLRL -(SP)
PUSHL #<DSC$K_CLASS_D@<DSC$B_CLASS@TOBITS>>!-
<DSC$K_DTYPE_T@<DSC$B_DTYPE@TOBITS>>

$lib_getjpi_S item_code = #JPI$_PRCNAM,-
resultant_string = (SP)
.BRANCH_LIKELY ; assume success andd tell compiler
BLBS R0,10$ ; continue if LIB$GETJPI successful
RET

10$: MOVZBL (AP),R0 ; get the passed in argument count

.DISABLE FLAGGING ; disable compiler informational
20$: PUSHL (AP)[R0] ; copy passed arguments to stack
.ENABLE FLAGGING ; enable compiler informational
SOBGTR R0,20$ ; one by one until all exhausted

MOVZBL (AP),R0 ; get the passed in argument count
PUSHAL (SP)[R0] ; process name is at end of list
PUSHL #2 ; MC$PCS_TRCBCK has 2 FAO arguments
PUSHL #MC$PCS_TRCBCK ; push the MC$PCS_TRCBCK error code

ADDL2 #3,R0 ; correct argument count for above

.DISABLE FLAGGING ; disable compiler informational
CALLS R0,G^LIB$SIGNAL ; signal the error(s)
.ENABLE FLAGGING ; enable compiler informational

;++
; Free up the memory acquired for the process name
; via the Dynamic String Descriptor on the stack.
;--

$str_free1_dx_S string_descriptor = (SP)

MOVL #SS$_NORMAL,R0

RET

.END

[Tom Adams]

On May 16, 12:39 pm, VAXman- @SendSpamHere.ORG wrote:

That works!

Thanks!

[Stephen Hoffman]

On 2013-05-16 03:14:07 +0000, John Reagan said:

> Recoding into C is much like shuffling the deck chairs on the Titanic.

Misread that as "deckchairs on the Itanic". Whoops. My bad. :-)

[VAXman-]

In article <e696970e-50d4-488b...@y5g2000yqy.googlegroups.com>, Tom Adams <w.tom...@gmail.com> writes:
>{...snip...}
>
>That works!
>
>Thanks!

Your welcome. I tend to use the $rtl$ROUTINESDEF macros because it makes it
so much more readable, especially, with the named arguments. Both the LIB$
and STR$ RTLs also accept dynamic string descriptors and will allocate what
is needed for string output making static storage for strings in data PSECTs
unnecessary. If they are allocated on the stack, be sure to deallocate them
(ie. STR$FREE1_DX) before cleaning off the stack. Also, be forewarned that
there are errors in some of the macros defined in $LIBROUTINESDEF. For the
which have such problems, I've devised a "CALL" macro that allows me to call
LIB$whatever without the gore of myriad PUSH, MOV, CVT, etc., instructions
cluttering up the read.

[Tom Adams]

On May 16, 2:59 pm, VAXman- @SendSpamHere.ORG wrote:

I got this when I tried to link to the production system:

%LINK-W-MULPSC, conflicting attributes for psect CODE
in module PCS_TRCBCK file DSA0:[EES.SIM.SYS.OLB]PCS.OLB;1

Not sure what the problem is.

My guess is that the other 2 *.mar files in this system just have
"PSECT CODE" with no other attributes, so the attributes
you specified conflicted.

When I was testing your code, I just linked to a FORTRAN test program
that called PCS_TRCBCK with some
of the problem messages printed out.

[VAXman-]

In article <d937f128-b9b1-4214...@a8g2000yqp.googlegroups.com>, Tom Adams <w.tom...@gmail.com> writes:
>On May 16, 2:59=A0pm, VAXman- @SendSpamHere.ORG wrote:
>> In article <e696970e-50d4-488b-b376-23bd02134...@y5g2000yqy.googlegroups.=

>com>, Tom Adams <w.tom.ad...@gmail.com> writes:
>>
>> >{...snip...}
>>
>> >That works!
>>
>> >Thanks!
>>

>> Your welcome. =A0I tend to use the $rtl$ROUTINESDEF macros because it mak=
>es it
>> so much more readable, especially, with the named arguments. =A0Both the =
>LIB$
>> and STR$ RTLs also accept dynamic string descriptors and will allocate wh=
>at
>> is needed for string output making static storage for strings in data PSE=
>CTs
>> unnecessary. =A0If they are allocated on the stack, be sure to deallocate=
> them
>> (ie. STR$FREE1_DX) before cleaning off the stack. =A0Also, be forewarned =
>that
>> there are errors in some of the macros defined in $LIBROUTINESDEF. =A0For=
> the
>> which have such problems, I've devised a "CALL" macro that allows me to c=
>all
>> LIB$whatever without the gore of myriad PUSH, MOV, CVT, etc., instruction=

>s
>> cluttering up the read.
>>
>> --

>> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0VAXman(at)TMESIS(=

>dot)ORG
>>
>> Well I speak to machines with the voice of humanity.
>

>I got this when I tried to link to the production system:
>
>%LINK-W-MULPSC, conflicting attributes for psect CODE
> in module PCS_TRCBCK file DSA0:[EES.SIM.SYS.OLB]PCS.OLB;1
>
>Not sure what the problem is.
>
>My guess is that the other 2 *.mar files in this system just have
>"PSECT CODE" with no other attributes, so the attributes
>you specified conflicted.

Change ".PSECT CODE,NOWRT,EXE,5" to read ".PSECT $_$CODE$_$,NOWRT,EXE,5
I hate leaving the .PSECT attribute undefined but you could also just
change it to ".PSECT CODE".

>When I was testing your code, I just linked to a FORTRAN test program
>that called PCS_TRCBCK with some
>of the problem messages printed out.

[David Froble]

Stephen Hoffman wrote:
> On 2013-05-16 03:14:07 +0000, John Reagan said:
>
>> Recoding into C is much like shuffling the deck chairs on the Titanic.
>
> Misread that as "deckchairs on the Itanic". Whoops. My bad. :-)
>
>

About the same thing, huh ??

[David Froble]

Just wondering, what would be your response to someone calling this butt
ugly MACRO code?

:-)

Just kidding, I read right through it, one pass, no problems. Though,
the use of "FLAGGING" is something I've never seen before.

[David Froble]

Yeah, more than one PSECT with the same name can be an issue. I always
try to use unique names.

The "fun" with MACRO is you either do a lot of it, or you don't do any.
Your mind needs to be thinking in a much more detailed and focused way
when writing MACRO. I don't do much anymore, but I always thought it
was fun.

[VAXman-]

In article <kn8744$r15$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
{...snip...}

>Just wondering, what would be your response to someone calling this butt
>ugly MACRO code?

That which we call a rose...

>Just kidding, I read right through it, one pass, no problems. Though,

>the use of "FLAGGING" is something I've never seen before. In this bit
of code, the PUSHL (AP)[R0] will emit:

%AMAC-I-RUNTIMSTK, run time stack differences prevent accurate stack tracing

and the CALLS R0,G^LIB$SIGNAL will emit:

%AMAC-I-VARSIZSTK, variable-sized stack update prevents accurate stack tracing

Both are informational and expected (at least, I expected them) so I use
the .DISABLE FLAGGING to suppress the messages. I re-enable flagging as
soon as possible so that *unexpected* messages will still be seen when or
if they are emitted.

The Macro compiler will emit informational messages about things which it
finds to be or consider inefficient or possible coding issues.

[John Reagan]

wrote in message news:00AD374E...@SendSpamHere.ORG...

> %AMAC-I-RUNTIMSTK, run time stack differences prevent accurate stack
> tracing

> and the CALLS R0,G^LIB$SIGNAL will emit:

> %AMAC-I-VARSIZSTK, variable-sized stack update prevents accurate stack
> tracing

> Both are informational and expected (at least, I expected them)

As FYI, the compiler normally tries to turn PUSHLs into direct moves into
R16-R21 when it can tell that the PUSHL is loading a particular argument
slot. In the cases where it cannot, the PUSHLs are turned into real 32-bit
pushes on the stack. We then call a helper routine AMAC$EMUL_CALL which
then unpacks the stack at run-time into the appropriate R16-R21 slots,
expands the other arguments from 32 to 64 bits and transfers control the
target routine. These messages are attempting to tell you that if you think
you can recode something.

John

[George Cornelius]

Thanks, John. Great stuff. And it helped me understand the extra
subroutine that was being executed when I tried my own code.

For anyone who is interested, below is subroutine argcopy, which
does just an arglist copy, while adding one extra argument, followed
by calling entry point junksubr with the generated args.

Also listed is actest.mar, which contains the testing infrastructure.
Yep, it doesn't print anything - you have to put a breakpoint at the
ret statement in junksubr and examine the arglist to verify it's
correct. 'Compile' with /NOOPTIMIZE/DEBUG and link with /DEBUG
if you want single stepping in the debugger to work as expected
as you try this out.

My solution is minimalist - I just tried copying a variable length
argument list. As a retread Macro-11 programmer I tend to write
things that almost look like they'll work in Macro-11, but you'll
notice I actually forced myself to use advanced VAX addressing
modes like 4(ap)[r4] once or twice!

George

> John

BEGIN Example

$ type argcopy.mar ! Simple arg copy subr
; argcopy.mar gfc 20130601 Try copying from one VAX style arglist to another
;From: TSMALL.MAR GFC 2000-11-29 Test
.title argcopy copy an arglist with one extra arg

.psect pure__code,exe,nowrt,quad
;
; Do very little.
;
argcopy::
; .call_entry max_args=0,home_args=false,output=<r0>,preserve=<>
.call_entry max_args=32,home_args=true,preserve=<r4,r5>
movl (ap),r4
moval 4(ap)[r4],r5
10$:
pushl -(r5)
sobgtr r4,10$
pushal junkdsc
addl3 #1,(ap),r4
calls r4,junksubr
movl #1,r0
ret
;
.psect __data,wrt,noexe,quad
.align quad
junkdsc:
.ascid |This is just here to look good. Doesn't do anything|
.end

$ type actest.mar ; Test infrastructure.
; actest.mar gfc 20130601 Try argcopy.mar
.psect pcode,nowrt,exe,quad
; .entry atbegin,^M<>
atbegin::
.call_entry max_args=0,home_args=true,preserve=<>
callg #arglist,g^argcopy
ret
; $exit_s
junksubr::
.call_entry max_args=33,home_args=true,preserve=<r4,r5>
movl (ap),r4
moval 4(ap),r5
ret
.psect idata,wrt,noexe,quad
.align quad
arglist::
.long <arglist_e-.>/4-1
.long 11,10,9,8,7,6,5,4,3,2,1
arglist_e=.
.end atbegin

$ sho cpu ! The test system

System: EISNER, AlphaServer DS20 500 MHz

[...]

END Example