On Mon, Jun 4, 2012 at 2:45 AM, robin robi...@dodo.com.au wrote:
There's no need to be scared of an odd value.
It is, after all, the assembler that calculates displacements.
If it bothers you, make it 4092. Still no extra instruction needed.
Since most of the time you just new a few more
On 6/3/2012 8:52 AM, John Gilmore wrote:
Gerhard's point is not so easily dismissed; but 1) it is
self-defeating for the technology if pushed very far: it freezes
software in a posture that is now more than fifteen years behind the
state of the art; and 2) the market for even moderately-priced
Odd (or nonconsecutive) Base registers
Please-
If there is ever a need to calculate a ZAP to this code with crossing
the boundary between two registers- it will cause major headaches-
The PLS compiler does it- but this is not an argument to do it.
--
Martin
Pi_cap_CPU - all you ever need
... said enough, maybe too much, about this topic
Since the thread is still not dead- here is my point:
Use of relative immediate feature is the way to go. The time it takes
to convert a module from Bxx type to Jxxx is neglectable in comparison
to finding an unused register (or restructuring
From: Rob van der Heij
Sent: Monday, 4 June 2012 4:41 PM
Since most of the time you just new a few more bytes anyway ;-)
?? Doesn't make sense.
From: Rob van der Heij
Sent: Monday, 4 June 2012 4:41 PM
On Mon, Jun 4, 2012 at 2:45 AM, robin robi...@dodo.com.au wrote:
There's no need to be scared of an odd value.
It is, after all, the assembler that calculates displacements.
If it bothers you, make it 4092. Still no extra instruction
On Mon, Jun 4, 2012 at 12:20 PM, robin robi...@dodo.com.au wrote:
Even with the nonsense word changed a la Martin,
your response still doesn't make sense.
Sorry, as Martin noticed my head and fingers had disconnected...
Typically I find the module just slightly extend the 4K after a small
I have yet to find that VSE-customer that pays for Vendor-software and
has no money for hardware or operating-system-software AND demands
new features.
We have several that meet this requirement. Think about the VSE 2.6 on
P390 ESL boxes.
Tony Thigpen
-Original Message -
From:
I think it may have been an parody of a joke:
Question: How much money is enough?
Answer: Just a little bit more.
In assembler, it is how many bytes do you need to be resolvable to a valid
offset? just a few more.
It's why I (as a customer only), love doing baseless programming. I separate
the
Tony,
I have yet to find that VSE-customer that pays for Vendor-software and
has no money for hardware or operating-system-software AND demands
new features.
We have several that meet this requirement. Think about the VSE 2.6 on
P390 ESL boxes.
I can imagine customers running that- but
Martin,
As the say options are like ...everyone had one...your entitled to yours
Scott ford
www.identityforge.com
On Jun 4, 2012, at 8:27 AM, Martin Truebner mar...@pi-sysprog.de wrote:
Tony,
I have yet to find that VSE-customer that pays for Vendor-software and
has no money for hardware
That was a typo, opinionsour customers usually dictate needs many times
Scott ford
www.identityforge.com
On Jun 4, 2012, at 9:00 AM, Scott Ford scott_j_f...@yahoo.com wrote:
Martin,
As the say options are like ...everyone had one...your entitled to yours
Scott ford
Thanks Gerhard, I feel the same way, especially when you work for a small
company and your the only one writing Assembler, with customers asking for
changes
Scott ford
www.identityforge.com
On Jun 4, 2012, at 2:49 AM, Gerhard Postpischil gerh...@valley.net wrote:
On 6/3/2012 8:52 AM, John
I have seen many old IBM modules (in dumps, microfiche, etc.) in which the
first few instructions are something like this:
MODULE USING *,R15
LRR12,R15
LA R11,4095(,R12)
DROP R15
USING MODULE,R12
USING MODULE+4095,R11
This allows 8,191 bytes of
Bill,
Amen, I first wrong BAL on a 360/20, didn't have the 1401 exposure ..man half
words were real important
Scott ford
www.identityforge.com
On Jun 4, 2012, at 11:15 AM, Bill Fairchild bfairch...@rocketsoftware.com
wrote:
I have seen many old IBM modules (in dumps, microfiche, etc.) in
The code we use here at my job usually has very large modules and used several
base registers. I have seen the following technique used:
MYCSECT CSECT
USING *,R15
B BYID
ID DCC'module-name'
BASESDCA(MYCSECT)
DCA(MYCSECT+4096)
DC
i guess you guys would never set the base to he last byte of the program or
dsect; having all negative displacements.
No such thing as a negative displacement. A displacement is more like an
unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit
displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement).
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
The displacement for A is treated as a 12-bit
*unsigned* binary integer. The displacement for AY,
AG, AGF, AGSI and ASI, is treated as a 20-bit *signed*
binary integer.
I contributed the asterisks. The rest is from the POps.
--
Regards, Gord Tomlin
Action Software International
(a division of
OOPS. Thanks for the correction! So you could use the 20 bit offset in a
negative direction from the end of the module. Personally, I don't think that
I'll try that! And I generally use baseless coding for things in the CSECT,
anyway.
--
John McKown
Systems Engineer IV
IT
Administrative
On Mon, 4 Jun 2012 14:20:09 -0500 McKown, John
john.mck...@healthmarkets.com wrote:
:No such thing as a negative displacement. A displacement is more like an
unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit
displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long
John McKown writes:
begin extract
No such thing as a negative displacement. A displacement is more like
an unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12
bit displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long
displacement)
/end extract
This is is correct only
Someone wrote:
MYCSECT CSECT
USING *,R15
B BYID
ID DCC'module-name'
BASESDCA(MYCSECT)
DCA(MYCSECT+4096)
DCA(MYCSECT+2*4096)
DCA(MYCSECT+3*4096)
BYID DS0H
LMR9,R12,BASES
DROP
snip
But, why the DS 0H instead of putting the label on the LM?
-- glen
I do the same thing for labels to code. Why? Hum, I guess from reading the
HASP code long ago. Also, it makes it easier to insert a new instruction at
that logical point in the program without remembering to remove the
I don't see where this is possible in HLASM. But some languages all a _
character in numeric literals, and simply ignoring it. Often used in decimal
literals to separate thousands, and in binary literals to separate into nybbles
(4 bits). It is much easier to recognize 16_777_216 than 16777216.
(snip, I wrote)
But, why the DS 0H instead of putting the label on the LM?
I do the same thing for labels to code. Why? Hum, I guess
from reading the HASP code long ago. Also, it makes it
easier to insert a new instruction at that logical point in
the program without remembering to remove
On Jun 4, 2012, at 15:31, John Ehrman wrote:
Blank separators were introduced for quite-delimited numeric constants in
HLASM R3.
IOW they're permitted in DC, but not in EQU where they're
not quite delimited.
Sigh.
-- gil
From: John Gilmore
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Tuesday, 5 June 2012 7:37 AM
As an optional usage in coded-arithmetic and hexadecimal constants,
where it is unambiguous, this is an excellent idea.
It has been available in PL/I for a long time, where I may write
Declare Fmax
I have taxed other people with not having mastered details, but I must
admit that I did not know that
| DCF'2 147 483 647'
was licit. In the interests of coherence, it should be possible to write
| DCF'2_147_483_647'
if it is possible to write
|FMAX EQU
29 matches
Mail list logo
