Fully support 32-bit EQUs (maybe even 64-bit EQUs as well)

The processing of an assembler expression (a hugely complex process in the general case) is the same in all contexts; there is nothing special about EQU, and neither should there be.

In most places where the assembler accepts a number, it will also accept an expression, which is always evaluated as a 31-bit signed expression, regardless of the context. The numeric value of a symbol, including one defined with EQU, is always a 31-bit signed number too.

Hexadecimal self-defining constants (as well as binary and character constants) represent signed 31-bit numbers in that context, and cannot go outside that range. Regardless of syntax, supporting values outside that range would require a total rewrite of expression processing and many other areas that currently store numbers as signed fullwords. This might eventually be worth while for 63-bit expressions, but would require a huge amount of work.

Hi John, Thanks for your response. I'd like to make a couple of comments:

First, I think if you separated the 64 bit issue from the 32 bit issue, that would make the 32-bit issue more addressable. Yes, full 64-but support would be perfect. But please don't let "the perfect" be the enemy of "the good".

Second, WRT "It is not at all clear how this could be notated and implemented", I made a suggestion that you do it with a new statement: LEQU. ["L" for logical, i.e. unsigned, value.] Your response did not address that idea.

Third, WRT 64 bit support, the problem with the XD'hhh' idea comes when EQU operands are computations involving values that are not hex strings. I think it would be overly complex and a mistake to make "D-ness" an attribute of the operands when what is really wanted is for D-ness to be the attribute of the result. I think it would be better for the user (and perhaps easier for you all to code) if you implemented a DEQU statement for the 64 bit case. The advantages are:
- It is easier to understand for the user as compared to yet another of the myriads of attributes and operands that already exist.
- I bet it would be easier to code at your end as well.

Best,
Dave

The assembler currently evaluates all general expressions using 31-bit signed arithmetic, regardless of context.  Unsigned values are only supported in specific contexts, such as the value of an unsigned fullword DC constant.

This request is therefore effectively asking for some way to support unsigned 32-bit arithmetic in general expressions, as an alternative to 31-bit signed arithmetic.  It is not at all clear how this could be notated and implemented, and it seems it would be a huge change.  It is hard to see how a minor inconvenience relating to trying to treat EQU values as unsigned could justify such a major change.

We have of course had requests to support 64-bit arithmetic (or more specifically signed 63-bit arithmetic) in general assembler expressions.  This would require huge changes to the internals of the assembler, and some changes to the language too, in that for example X'80000000' would still need to represent a negative number for compatibility reasons, with leading sign bits, so a new notation such as XD'80000000' would be needed to represent the equivalent doubleword unsigned value.  If that functionality is implemented at some point in the future, that would also provide a solution to the current requirement.

- Jonathan Scott, HLASM