Paul G.
I like your idea:
>> multiple constants within a literal.
That would make it very easy for the implementer (the good people
around John E) and the writers of HLASM-code would only need and extra
empty constant for very few instructions-
But it lacks the beauty of a solution invisable to
John,
excellent...
and I assume that you did mention VSE in your requirement as
well- Which should not matter since it is the same piece of code
anyway (but ).
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
This whole discussion seems to miss the reason for using a literal(i.e. to
group together constants in order of their storage alignment requirements).
This code will do what he wants with any alignment error...
LARL 3,LTORG
USING 3,LTORG
LA 3,=x'23'
DROP 3
...
Don,
A useful application of a Count 1-Bits instruction could be page allocation.
For example, let us consider the following case.
My system is configured with 1M segments and 4K pages. A segment map of 32
bytes can be used to map the status of the 256 pages comprising the segment.
I issue a G
On 3 August 2010 07:55, Don Higgins wrote:
> I though I'd start a new thread with this subject so those searching index
> can find it.
I stumbled across a recent paper in computational linguistics that
refers to the usefulness of such a feature. The paper is far too
specialized for me, but perh
Paul Gilmartin wrote:
On Aug 21, 2010, at 14:59, Steve Comstock wrote:
John P. Baker wrote:
When using the LARL instruction to reference a literal (i.e., =X'..'), I
receive an ASMA058E error message due to the literal not being property
aligned (on a halfword boundary).
1. LARL stores the add
On Aug 21, 2010, at 16:44, john gilmore wrote:
> The notion that "customers" cannot reasonably be deprived of literals
> suggests that what is in question is some fill-in-the-blanks situation. Such
> problems can be dealt with under the hood (bonnet), whether they be
> screen-input or macro ke
On Aug 21, 2010, at 14:59, Steve Comstock wrote:
> John P. Baker wrote:
>> When using the LARL instruction to reference a literal (i.e., =X'..'), I
>> receive an ASMA058E error message due to the literal not being property
>> aligned (on a halfword boundary).
>
> 1. LARL stores the address of the
John P. Baker wrote:
When using the LARL instruction to reference a literal (i.e., =X'..'), I
receive an ASMA058E error message due to the literal not being property
aligned (on a halfword boundary).
It would seem to me that when a relative instruction references a literal,
the assembler shoul
Tony,
A non-literal constant, if improperly aligned by the programmer, should be
flagged in error.
On the other hand, the placement of a literal constant is determined by the
assembler. That being the case, I believe that it is reasonable for the
assembler to provide correct alignment.
John P.
On 21 August 2010 17:27, John P. Baker wrote:
> There is no problem when the literal is specified as H'nn', F'nn', or of any
> other form which requires halfword or better alignment.
>
> Likewise, there is no problem with a binary, character, or hexadecimal
> literal whose representation consists
The notion that "customers" cannot reasonably be deprived of literals suggests
that what is in question is some fill-in-the-blanks situation. Such problems
can be dealt with under the hood (bonnet), whether they be screen-input or
macro keyword-parameter ones: query and note assembled lengths t
John Gilmore Ashland, MA 01721-1817 USA
Steve,
There is no problem when the literal is specified as H'nn', F'nn', or of any
other form which requires halfword or better alignment.
Likewise, there is no problem with a binary, character, or hexadecimal
literal whose representation consists of an even number of bytes.
However, a halfword
John P. Baker wrote:
When using the LARL instruction to reference a literal (i.e., =X'..'), I
receive an ASMA058E error message due to the literal not being property
aligned (on a halfword boundary).
It would seem to me that when a relative instruction references a literal,
the assembler shoul
All,
The following requirement has been submitted to IBM in respect to literal
alignment when using relative addressing.
HLASM should offer an option having the effect that any literal referenced
by an instruction using relative addressing will be flagged to be aligned on
a halfword boundary, con
Gil,
I found the same thing.
However, I believe that it is reasonable to expect that HLASM, when
referencing a literal by way of an instruction using relative addressing,
should force the literal to a halfword boundary.
Since this is not presently the case, I plan to submit a requirement to IBM
On Aug 21, 2010, at 12:04, John P. Baker wrote:
> When using the LARL instruction to reference a literal (i.e., =X'..'), I
> receive an ASMA058E error message due to the literal not being property
> aligned (on a halfword boundary).
> ...
> Is there any known method by which to force an otherwise
On Aug 21, 2010, at 12:04, John P. Baker wrote:
> When using the LARL instruction to reference a literal (i.e., =X'..'), I
> receive an ASMA058E error message due to the literal not being property
> aligned (on a halfword boundary).
>
> It would seem to me that when a relative instruction referenc
When using the LARL instruction to reference a literal (i.e., =X'..'), I
receive an ASMA058E error message due to the literal not being property
aligned (on a halfword boundary).
It would seem to me that when a relative instruction references a literal,
the assembler should force an otherwise un
20 matches
Mail list logo
