EQU and critical expression

The recent change to make the argument to EQU a critical
expression 
broke some of my code in a hard to fix way.

It also doesn't seem right that EQU should require a
critical expression 
at all.  Rather, if its argument is a forward expression,
then the whole 
EQU is unresolved and should not be permitted as a critical
expression. 
  I don't recall the exact failure scenario that prompted
the change, 
but I'd like to revisit it.

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

On Mon, 12 May 2008 17:04:42 -0700
"H. Peter Anvin" <hpazytor.com> wrote:

> The recent change to make the argument to EQU a
critical expression 
> broke some of my code in a hard to fix way.

There was no such change. The comments in parser.c, which
have been
there for as long as I can recall, say:

    /*
     * RESB, RESW and RESD cannot be satisfied with
incorrectly
     * evaluated operands, since the correct values _must_
be known
     * on the first pass. Hence, even in pass one, we set
the
     * `critical' flag on calling evaluate(), so that it
will bomb
     * out on undefined symbols. Nasty, but there's nothing
we can
     * do about it.
     *
     * For the moment, EQU has the same difficulty, so
we'll
     * include that.
     */

What was changed was the behavior that, when optimization
was turned on,
ALL critical error checking was turned off.

>   I don't recall the exact failure scenario that
prompted the change

The exact failure scenario was that, when optimization was
turned on,
using EQU to set a label equal to a forward referenced label
did not
produce a "symbol `%s%s' not defined before use"
message. At the time,
you expressed the opinion that such a message was the
desired behavior.

> but I'd like to revisit it

Fine with me, but merely reverting to the 'no such thing as
a critical
error, so something else must be wrong' behavior does not
seem to me to
be sufficient. We might be better off to drop entirely the
concept of
allowing the user to specify a specific number of
optimization passes
(which can still produce phase errors) and, instead, to use
the command
line switch to control what types of optimization to
perform, rather
than make them guess at how many passes it takes to do
them.

-- 
Chuck 
htt
p://www.pacificsites.com/~ccrayne/charles.html


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

Charles Crayne wrote:
> 
> What was changed was the behavior that, when
optimization was turned on,
> ALL critical error checking was turned off.
> 

Right, that's obviously totally wrong.

>>   I don't recall the exact failure scenario that
prompted the change
> 
> The exact failure scenario was that, when optimization
was turned on,
> using EQU to set a label equal to a forward referenced
label did not
> produce a "symbol `%s%s' not defined before
use" message. At the time,
> you expressed the opinion that such a message was the
desired behavior.
> 

Hm... I might have misunderstood the problem at the time.  I
guess I 
need to look back at the old emails.

>> but I'd like to revisit it
> 
> Fine with me, but merely reverting to the 'no such
thing as a critical
> error, so something else must be wrong' behavior does
not seem to me to
> be sufficient. We might be better off to drop entirely
the concept of
> allowing the user to specify a specific number of
optimization passes
> (which can still produce phase errors) and, instead, to
use the command
> line switch to control what types of optimization to
perform, rather
> than make them guess at how many passes it takes to do
them.

Obviously, I'm not suggesting that we should stop checking
for critical 
expressions; not at all.  I'm just questioning if EQU should
be a 
critical expression.  The tricky bit, I guess, is that the
user has a 
reasonable expectation that an EQU which is a valid critical
expression 
should be usable in a critical context, whereas one should
be able to 
use forward references in an EQU that is *not* used in a
critical 
expression.

Does anyone see anything fundamentally wrong with that
concept?  In 
particular, the comment that "for the moment EQU has
the same 
difficulty" seems to imply that it wasn't supposed to
have had...

	-hpa


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

On Mon, 02 Jun 2008 09:22:26 -0700
"H. Peter Anvin" <hpazytor.com> wrote:

> Did you ever get a chance to look at this?

I got a ways into it before I got diverted to a higher
priority
project, but I should be able to get back to it in a few
more days.

The current status is that removing equ from the critical
expression
list does indeed prevent an error message at the point where
the equ
expression occurs, but leaves the symbol table entry
pointing at the
wrong section. This has something to do with the way the
forward
reference table is built, but I do not yet know exactly
why.

-- 
Chuck 
htt
p://www.pacificsites.com/~ccrayne/charles.html


------------------------------------------------------------
-------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://
sourceforge.net/services/buy/index.php
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel