🚀 go-pugleaf

John,

thanks for your quick answer. I've taken today's luch break
to test your remarks. I think there's been a misunderstanding.

You state the D' attribute was designed especially for the
purpose I had in mind. Well - it does not test whether a field
will be defined - it only tests whether or not a field has been
defined prior to the D' attribute reference.

This is a very useful feature, but in this case, I need to know
in advance whether or not invocation of the mapping macro
will or will not generate a given field. D' does not tell in advance,
not even in open code....

I think Roland Schiradin was closer by stating that it is impossible
to check in advance. I'll have to create my own solution.

Thanks,
Abe.
===

----- Original Message -----
From: "John R. Ehrman (408-463-3543 T/543-)" <ehrman@vnet.ibm.com>
To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Sent: Tuesday, October 03, 2006 8:46 PM
Subject: Look-ahead question


> The D' attribute reference will return 0 if the symbol is not
> defined, or 1 if it is; both tests are made at the position in
> the program where the attribute reference occurs. D' is meant
> to do just what you need (and was invented for that purpose).
>
> John Ehrman
>    (------------------ Referenced Note Follows --------------------)
> Date:         Tue, 3 Oct 2006 20:37:53 +0200
> From: Abe Kornelis <abe@bixoft.nl>
>
> Does anybody know of a way to tell in advance whether or not a
> specific field will be defined before its mapping macro is invoked?
>
> I have not been able to find a solution.
>
> After a field has been defined (DS or DC) I can of course use the
> D' attribute. But to my knowledge, this will not work *before* the
> field in question has been defined.
>
> I need to take action before the field is actually defined...
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.407 / Virus Database: 268.12.12/462 - Release Date: 3-10-2006
>
>

Abe Kornelis wrote:
> You state the D' attribute was designed especially for the
> purpose I had in mind. Well - it does not test whether a field
> will be defined - it only tests whether or not a field has been
> defined prior to the D' attribute reference.
>
> This is a very useful feature, but in this case, I need to know
> in advance whether or not invocation of the mapping macro
> will or will not generate a given field. D' does not tell in advance,
> not even in open code....

If you can foretell the future, can you then take steps to alter it?
Such a conundrum/paradox might be fun to ponder while under the
influence of mind-altering chemicals. But, in the real world of
assembler language programming, a "crystal ball" seems like an
unreasonable request to me.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edjaffe@phoenixsoftware.com
http://www.phoenixsoftware.com/

http://www.fortran.com/come_from.html

Mike

At 11:07 AM 10/4/2006 -0700, you wrote:
>Abe Kornelis wrote:
>>You state the D' attribute was designed especially for the
>>purpose I had in mind. Well - it does not test whether a field
>>will be defined - it only tests whether or not a field has been
>>defined prior to the D' attribute reference.
>>
>>This is a very useful feature, but in this case, I need to know
>>in advance whether or not invocation of the mapping macro
>>will or will not generate a given field. D' does not tell in advance,
>>not even in open code....
>
>If you can foretell the future, can you then take steps to alter it?
>Such a conundrum/paradox might be fun to ponder while under the
>influence of mind-altering chemicals. But, in the real world of
>assembler language programming, a "crystal ball" seems like an
>unreasonable request to me.
>
>--
>Edward E Jaffe
>Phoenix Software International, Inc
>5200 W Century Blvd, Suite 800
>Los Angeles, CA 90045
>310-338-0400 x318
>edjaffe@phoenixsoftware.com
>http://www.phoenixsoftware.com/
>




Michael Stack                 e-mail:   mstack@niu.edu
                               ear-mail: 1.815.753.9447
Computer Science Department   fax:      1.815.753.0342
Northern Illinois University  www:      http://mstack.cs.niu.edu
DeKalb, IL  60115             skype:    callto://mstack

Edward Jaffe <edjaffe@phoenixsoftware.com> wrote:

> If you can foretell the future, can you then take steps to alter it?
> Such a conundrum/paradox might be fun to ponder while under the
> influence of mind-altering chemicals. But, in the real world of
> assembler language programming, a "crystal ball" seems like an
> unreasonable request to me.

It would be possible to do with more than two passes, though
I don't know of any assemblers that do it.

For assemblers, a similar problem comes up when deciding
between short and long branch instructions.

LaTeX has a related problem for doing table of contents and
other page references.  The LaTeX solution involves running
LaTeX multiple times, each time it reads in a file that it
previously wrote.  Usually this converges to the right solution
fairly fast, though there could be cases that don't converge.

-- glen

Michael Stack <mstack@niu.edu> wrote:

> http://www.fortran.com/come_from.html

There is also debug packets and the AT statement
implemented in the Fortran G compiler, somewhat
similar to what one could do with COME FROM statements.

It lets you put debugging code at the end of the
subprogram, and print out or otherwise check values
at the appropriate place in the program.

I never tried it, and don't know how they implemented it.

-- glen

On Wed, 4 Oct 2006 11:07:54 -0700 Edward Jaffe <edjaffe@phoenixsoftware.com>
wrote:

:>Abe Kornelis wrote:
:>> You state the D' attribute was designed especially for the
:>> purpose I had in mind. Well - it does not test whether a field
:>> will be defined - it only tests whether or not a field has been
:>> defined prior to the D' attribute reference.

:>> This is a very useful feature, but in this case, I need to know
:>> in advance whether or not invocation of the mapping macro
:>> will or will not generate a given field. D' does not tell in advance,
:>> not even in open code....

:>If you can foretell the future, can you then take steps to alter it?
:>Such a conundrum/paradox might be fun to ponder while under the
:>influence of mind-altering chemicals. But, in the real world of
:>assembler language programming, a "crystal ball" seems like an
:>unreasonable request to me.

Allow a first pass to get as much symbol information as possible, and then
start assembling on the second pass.

I find DSECTs at the beginning of the program to be quite ugly.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.