New file uploaded to H390-MVS

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

New file uploaded to H390-MVS

Hercules390 - Mvs mailing list

Hello,


This email message is a notification to let you know that
a file has been uploaded to the Files area of the H390-MVS
group.


  File        : /Temporary.trash/ASMSTY.jcl
  Uploaded by : somitcw <[hidden email]>
  Description : Sample STY MACRO


You can access this file at the URL:
https://groups.yahoo.com/neo/groups/H390-MVS/files/Temporary.trash/ASMSTY.jcl


To learn more about file sharing for your group, please visit:
https://help.yahoo.com/kb/index?page=content&y=PROD_GRPS&locale=en_US&id=SLN15398


Regards,


somitcw <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

'STY' instruction macro

Hercules390 - Mvs mailing list
Apologies for jumping into the middle of this conversation and not reviewing whether this was already discussed or not (I'm not familiar with the IFOX assembler), but if it supports SCONs (S-type address constants), then wouldn't the following suffice?

         MACRO
&STY     STY   &R1,&OP2
&STY     DC    0H'0',X'E3',AL.4(&R1,0),S(&OP2),X'0050'
         MEND

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
 - - - In [hidden email], <david.b.trout@...> wrote:

> Apologies for jumping into the middle of this conversation and not
>reviewing whether this was already discussed or not (I'm not familiar
>with the IFOX assembler), but if it supports SCONs (S-type address
>constants), then wouldn't the following suffice?
> MACRO
> &STY STY &R1,&OP2
> &STY DC 0H'0',X'E3',AL.4(&R1,0),S(&OP2),X'0050'
> MEND
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com http://www.softdevlabs.com
> mail: fish@... mailto:fish@...

Two issues.

1. It doesn't fix the reported problem of the index register
not being handled properly.

2. The length of label &STY is not set to 6.

Your code is an improvement over the initial MACRO where
the base register was put in the index register location.

Overlaying an LA for load instructions and
overlaying an STC for store instructions works best.
( Stores are not allowed to store in the literal pool )
( No, I don't know why )
Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 4/5/2017 11:45 AM, ''Fish' (David B. Trout)' [hidden email]
[H390-MVS] wrote:
> Apologies for jumping into the middle of this conversation and not reviewing whether this was already discussed or not (I'm not familiar with the IFOX assembler), but if it supports SCONs (S-type address constants), then wouldn't the following suffice?
>
>           MACRO
> &STY     STY   &R1,&OP2
> &STY     DC    0H'0',X'E3',AL.4(&R1,0),S(&OP2),X'0050'
>           MEND
You're back at the start of this thread. S constants don't accept things
like (,R4) 0(R4,R5) oe var(rx), all of which are legal in STY, STG, etc.



Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

Reply | Threaded
Open this post in threaded view
|

Re: New file uploaded to H390-MVS

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 4/5/2017 10:20 AM, [hidden email] wrote:
> You can access this file at the URL:
> https://groups.yahoo.com/neo/groups/H390-MVS/files/Temporary.trash/ASMSTY.jcl
You have a comment "would ORG , be better". Definitely not, as your
macro could be imbedded in code that already uses ORG, and a plain ORG
could end up anywhere.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
somitcw wrote:

[...]
> Two issues.
>
> 1. It doesn't fix the reported problem of the
> index register not being handled properly.
>
> 2. The length of label &STY is not set to 6.


Gerhard Postpischil wrote:

> You're back at the start of this thread. S constants
> don't accept things like (,R4) 0(R4,R5) or var(rx),
> all of which are legal in STY, STG, etc.

S constants have never (and will never) support index registers.  An SCON is base and displacement only (X'BDDD').  The operand-1 register and index register are handled separately by the "AL.4" address constant, not by the SCON which follows it.

So... to address both somitcw's 6-byte label concern as well as your and somitcw's index register concern, I hereby offer version 2 of my' STY' macro:


            MACRO
   &STY     STY   &R1,&OP2(&RX)
            DC    0H'0'         align to halfword boundary
   &STY     DS    0CL6          ensure STY label length is 6
            DC    0H'0',X'E3',AL.4(&R1,&RX),S(&OP2),X'0050'
            MEND


PLEASE NOTE that I'm not sure if "&OP2(&RX)" is valid macro syntax (I have not bothered to try and compile/test the above macro), but if it's not valid macro syntax then that can easily be fixed by simply using, for example, optional keyword operand syntax such as:


   &STY     STY   &R1,&OP2,RX=0


Would THIS not sufficiently address both of your concerns?

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
Fish
 
"&OP2(&RX)" is not valid.
 
Whether or not
 
&STY STY &R1,&OP2,RX=0
 
works really does not matter. That is not the documented syntax for any
instruction in the POPs. Consider the situation where code is being ported
to/from, let's say z/OS; one would not like having to have to modify all the
affected instructions. The assembly of an instruction using either HLASM on
z/OS or the macros on MVS 3.8 should accept identical instruction formats
and produce identical object code. Of course the 20-bit displacement
restriction still exists with the macros.
 
Shelby
 


  _____  

From: [hidden email] [mailto:[hidden email]]
Sent: Wednesday, April 05, 2017 7:58 PM
To: [hidden email]
Subject: RE: [H390-MVS] Re: 'STY' instruction macro


 

somitcw wrote:

[...]
> Two issues.
>
> 1. It doesn't fix the reported problem of the
> index register not being handled properly.
>
> 2. The length of label &STY is not set to 6.

Gerhard Postpischil wrote:

> You're back at the start of this thread. S constants
> don't accept things like (,R4) 0(R4,R5) or var(rx),
> all of which are legal in STY, STG, etc.

S constants have never (and will never) support index registers. An SCON is
base and displacement only (X'BDDD'). The operand-1 register and index
register are handled separately by the "AL.4" address constant, not by the
SCON which follows it.

So... to address both somitcw's 6-byte label concern as well as your and
somitcw's index register concern, I hereby offer version 2 of my' STY'
macro:

MACRO
&STY STY &R1,&OP2(&RX)
DC 0H'0' align to halfword boundary
&STY DS 0CL6 ensure STY label length is 6
DC 0H'0',X'E3',AL.4(&R1,&RX),S(&OP2),X'0050'
MEND

PLEASE NOTE that I'm not sure if "&OP2(&RX)" is valid macro syntax (I have
not bothered to try and compile/test the above macro), but if it's not valid
macro syntax then that can easily be fixed by simply using, for example,
optional keyword operand syntax such as:

&STY STY &R1,&OP2,RX=0

Would THIS not sufficiently address both of your concerns?

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]





Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
---In [hidden email], <shelby.beach@...> wrote :

> The assembly of an instruction using either
> HLASM on z/OS or the macros on MVS 3.8
> should accept identical instruction formats
> and produce identical object code. Of course
> the 20-bit displacement restriction still exists
> with the macros.

Could you elaborate on this please?

1. What is the z/OS limit?
2. What is the MVS 3.8j limit?
3. What is the normal MVS 3.8j limit?

I'm pretty sure number 3 is 0-4095.

I thought number 2 was 0-4095 also
for all these replacement macros,
but your message above seems to
indicate it is 20 bits, thus perhaps
0-1048575 or -524288 to 524287.

I thought number 1 was 20 bits,
and signed, so -524288 to 524287.

Thanks. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
 - - - In [hidden email], <kerravon86@...> wrote:

> - - - In [hidden email] mailto:[hidden email],
><shelby.beach@...> wrote :
>> The assembly of an instruction using either
>>HLASM on z/OS or the macros on MVS 3.8
>>should accept identical instruction formats
>>and produce identical object code. Of course
>>the 20-bit displacement restriction still exists
>>with the macros.
> Could you elaborate on this please?
> 1. What is the z/OS limit?

zOS is an operating system, not an assembler, and not an architecture.

RSE and RXE instructions use a positive 12 bit displacement.
RXY and RXY instructions use a signed 20 bit displacement.
Since the positive 12 bit displacements are withing the signed
20 bit displacement, you can use 20 bit displacements that
are really12 bit displacements with the high-order 8 bits set
to zero..

 2. What is the MVS 3.8j limit?

MVS 3.8j is an operating system, not an assembler, and not an architecture.

It can assemble whatever the assembler can assemble.
Zero displacement or 187 bit displacement makes no difference to MVS 3.8j.

 3. What is the normal MVS 3.8j limit?

MVS 3.8j normally runs on an architecture that uses either
no displacement or 12 bit displacement.

But we are not normal, are we.

> I'm pretty sure number 3 is 0-4095.

Ignoring the question, yes.
 
> I thought number 2 was 0-4095 also
>for all these replacement macros,
>but your message above seems to
>indicate it is 20 bits, thus perhaps
>0-1048575 or -524288 to 524287.
> I thought number 1 was 20 bits,
>and signed, so -524288 to 524287.
> Thanks. Paul.

If you LDMOD S37X, when that completes,
then Hercules handles 20 bit displacements.
MVS 3.8j knows nothing about it.
Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 6 April 2017 at 09:39, [hidden email] wrote:

> > The assembly of an instruction using either
> > HLASM on z/OS or the macros on MVS 3.8
> > should accept identical instruction formats
> > and produce identical object code. Of course
> > the 20-bit displacement restriction still exists
> > with the macros.
>
> Could you elaborate on this please?
>
> 1. What is the z/OS limit?
> 2. What is the MVS 3.8j limit?
> 3. What is the normal MVS 3.8j limit?


You seem to be muddling operating system, assembler, macro, and machine
constraints. I'm not sure what of all this is of real concern to you --
assuming that, as usual, your interest is mostly in GCCMVS-generated code.

If GCCMVS has no knowledge of 20-bit displacements, then it won't be
generating any. Since any 20-bit instructions will work fine with a 12-bit
displacement, as long as the high-order 8 bits of the 20 are zero, and
since the macros (Shelby's or even the earlier deficient ones) will
generate those bits as zero, there is nothing to worry about.

If you are considering expanding GCCMVS to be aware of larger (and signed)
displacements and therefore addressability, and to generate instructions
that exploit that feature, then let's discuss that separately from macros
that fill in gaps in the IFOX assembler. This kind of change to GCCMVS is
surely a much larger project, and I don't know if you are seriously looking
at tackling that, and if so, what it might accomplish.

Tony H.
Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
---In [hidden email], <tharminc@...> wrote :

>> and produce identical object code. Of course
>> the 20-bit displacement restriction still exists
>> with the macros.

> I'm not sure what of all this is of real concern
> to you

I was surprised to see a mention of a
20-bit limit. I thought these macros
had a 12-bit limit, at least when using
IFOX on MVS 3.8j.

That is all. Nothing to do with GCCMVS.
GCCMVS is not my only interest. I'm
curious as to what the limits are if I
code an assembler LG/STG.

Do the macros have an inherent 12-bit
limit, or do the macros generate 20-bit
offsets if assembled using ASMA90
on z/OS?

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list


Am 06.04.2017 um 19:10 schrieb [hidden email] [H390-MVS]:

>
> ---In [hidden email], <tharminc@...> wrote :
>
> >> and produce identical object code. Of course
> >> the 20-bit displacement restriction still exists
> >> with the macros.
>
> > I'm not sure what of all this is of real concern
> > to you
>
> I was surprised to see a mention of a
> 20-bit limit. I thought these macros
> had a 12-bit limit, at least when using
> IFOX on MVS 3.8j.
>
> That is all. Nothing to do with GCCMVS.
> GCCMVS is not my only interest. I'm
> curious as to what the limits are if I
> code an assembler LG/STG.
>
> Do the macros have an inherent 12-bit
> limit, or do the macros generate 20-bit
> offsets if assembled using ASMA90
> on z/OS?
>
> BFN. Paul.
>

One of the tasks that the ASSEMBLER has to do:

it must translate symbolic (relocatable) names to base register /
displacement values
(depending on current USING definitions, base address and base register)

If the ASSEMBLER (for example IFOX) has its origins in a period of time
where only machine instructions with 12 bit displacements existed,
then this computation of displacements is limited to 12 bits; in other
words:
the internal tables of symbolic names only contain 12 bits to store the
displacement of a value, given a certain base register, because larger
displacement
don't make any sense; if a displacement is larger, the name will not be
accessible
by this base register, because there is no machine instruction where
this displacement
can be stored (as it is larger than 12 bits).

This is the 12 bit displacement limit; it comes from the layout of some
internal
tables of the ASSEMBLER, and it has nothing to do with the operating system
or the macro facility.

When the first machine instruction appeared in history, that had a 20
bit displacement,
the internal tables of the ASSEMBLER which was modern at that time had
to be
extended to support displacements larger than 12 bits; otherwise this
ASSEMBLER
would not have been able to support 20 bit displacements in the modern
instructions.

HTH,
kind regards

Bernd

Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
Second question:

"Do the macros have an inherent 12-bit
limit, or do the macros generate 20-bit
offsets if assembled using ASMA90
on z/OS?"

the macros don't have any limit, but if you use an instruction
with a 12-bit-displacement as base to build a 20-bit displacement
instruction from it (example: STC, to build STY from it), you will
only get 12 bits on all platforms, because STC is limited to 12 bits.

This again has nothing to do with the macro processor (which is
a sort of special text processor, nothing more), but with the
ASSEMBLER and it's knowledge of instruction formats.

So it would be better to base "unknown" instructions with
20-bit displacements on other instructions with 20-bit displacements,
if there are any available (which of course will not be the case
with IFOX on MVS 3.8j).

BTW: this 12 to 20 bit expansion only works (IMO), because the
lower 12 bits of the 20 bit displacement are at exactly the same
place in the new instructions as the 12 bit displacements were
in the old instructions. IIRC, you have to take care of different
meaning of the displacements in some cases (when doing
some mappings, for example relative branches ... is that possible ???
Can relative branch instructions be constructed this way ???).

Kind regards

Bernd


Am 06.04.2017 um 19:47 schrieb Bernd Oppolzer:

>
>
>
> Am 06.04.2017 um 19:10 schrieb [hidden email] [H390-MVS]:
>>
>> ---In [hidden email], <tharminc@...> wrote :
>>
>> >> and produce identical object code. Of course
>> >> the 20-bit displacement restriction still exists
>> >> with the macros.
>>
>> > I'm not sure what of all this is of real concern
>> > to you
>>
>> I was surprised to see a mention of a
>> 20-bit limit. I thought these macros
>> had a 12-bit limit, at least when using
>> IFOX on MVS 3.8j.
>>
>> That is all. Nothing to do with GCCMVS.
>> GCCMVS is not my only interest. I'm
>> curious as to what the limits are if I
>> code an assembler LG/STG.
>>
>> Do the macros have an inherent 12-bit
>> limit, or do the macros generate 20-bit
>> offsets if assembled using ASMA90
>> on z/OS?
>>
>> BFN. Paul.
>>
>
> One of the tasks that the ASSEMBLER has to do:
>
> it must translate symbolic (relocatable) names to base register /
> displacement values
> (depending on current USING definitions, base address and base register)
>
> If the ASSEMBLER (for example IFOX) has its origins in a period of time
> where only machine instructions with 12 bit displacements existed,
> then this computation of displacements is limited to 12 bits; in other
> words:
> the internal tables of symbolic names only contain 12 bits to store the
> displacement of a value, given a certain base register, because larger
> displacement
> don't make any sense; if a displacement is larger, the name will not
> be accessible
> by this base register, because there is no machine instruction where
> this displacement
> can be stored (as it is larger than 12 bits).
>
> This is the 12 bit displacement limit; it comes from the layout of
> some internal
> tables of the ASSEMBLER, and it has nothing to do with the operating
> system
> or the macro facility.
>
> When the first machine instruction appeared in history, that had a 20
> bit displacement,
> the internal tables of the ASSEMBLER which was modern at that time had
> to be
> extended to support displacements larger than 12 bits; otherwise this
> ASSEMBLER
> would not have been able to support 20 bit displacements in the modern
> instructions.
>
> HTH,
> kind regards
>
> Bernd
>

Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
---In [hidden email], <berndoppolzer@...> wrote :

>> Do the macros have an inherent 12-bit
>> limit, or do the macros generate 20-bit
>> offsets if assembled using ASMA90
>> on z/OS?

> the macros don't have any limit, but if you use an instruction
> with a 12-bit-displacement as base to build a 20-bit displacement
> instruction from it (example: STC, to build STY from it), you will
> only get 12 bits on all platforms, because STC is limited to 12 bits.

Ah, I think I get it now, thanks.

I thought it was pretty miraculous that these
instructions could be generated using macros
at all. That seems amazingly lucky that IBM
chose a format that allowed this to happen.

Regardless, now that I understand the
inherent 12-bit universal limit created
by STC, then the original message
about a 20-bit limit appears to be wrong.
The limit is 12-bit, not 20-bit - a limit
created by the macro using STC etc.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Paul,
 
What I simply meant was that with the macros, there was no support for
20-bit displacements. So:
 
1. 20 bits
2. 12 bits
3. 12 bits (not sure what you mean by "normal MVS 3.8 limit)
 
Shelby
 


  _____  

From: [hidden email] [mailto:[hidden email]]
Sent: Thursday, April 06, 2017 6:39 AM
To: [hidden email]
Subject: RE: [H390-MVS] Re: 'STY' instruction macro


 

---In [hidden email], <shelby.beach@...> wrote :

> The assembly of an instruction using either
> HLASM on z/OS or the macros on MVS 3.8
> should accept identical instruction formats
> and produce identical object code. Of course
> the 20-bit displacement restriction still exists
> with the macros.

Could you elaborate on this please?

1. What is the z/OS limit?
2. What is the MVS 3.8j limit?
3. What is the normal MVS 3.8j limit?

I'm pretty sure number 3 is 0-4095.

I thought number 2 was 0-4095 also
for all these replacement macros,
but your message above seems to
indicate it is 20 bits, thus perhaps
0-1048575 or -524288 to 524287.

I thought number 1 was 20 bits,
and signed, so -524288 to 524287.

Thanks. Paul.




Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Oh My !
 
All I was trying to do was make sure that Fish understood that my macros did
nothing to address the restriction on 20-bit displacements (i.e. you could
not require a displacement greater than 12 significant bits). One last time:
the macros in SXMACLIB DO NOT SUPPORT 20-BIT DISPLACEMENTS. There is no way
that I (or others) have been able to come up with to do this in IFOX00, if
for no other reason because that assembler does not support bit manipulation
within a macro. This has nothing to do with Hercules. As somitcw pointed out
in a very complete explanation earlier, Hercules with S37X loaded supports
20-bit displacements just fine. The problem is making IFOX00 put out an
instruction with more than 12 significant displacement bits.
 
As far as my set of macros supporting 20-bit displacements when the macros
are used with HLASM, the answer is NO ! If you're running HLASM on z/OS you
don't need the macros, period.
 
Shelby
 


  _____  

From: [hidden email] [mailto:[hidden email]]
Sent: Thursday, April 06, 2017 10:11 AM
To: [hidden email]
Subject: Re: [H390-MVS] Re: 'STY' instruction macro


 

---In [hidden email], <tharminc@...> wrote :

>> and produce identical object code. Of course
>> the 20-bit displacement restriction still exists
>> with the macros.

> I'm not sure what of all this is of real concern
> to you

I was surprised to see a mention of a
20-bit limit. I thought these macros
had a 12-bit limit, at least when using
IFOX on MVS 3.8j.

That is all. Nothing to do with GCCMVS.
GCCMVS is not my only interest. I'm
curious as to what the limits are if I
code an assembler LG/STG.

Do the macros have an inherent 12-bit
limit, or do the macros generate 20-bit
offsets if assembled using ASMA90
on z/OS?

BFN. Paul.




Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
---In [hidden email], <shelby.beach@...> wrote :

> the restriction on 20-bit displacements
> (i.e. you could not require a displacement
> greater than 12 significant bits).

Yes, I understand now. The normal
20-bit displacement is restricted to
12 significant bits when using these
replacement macros.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: 'STY' instruction macro

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Hi Bernd,
 
Not sure how relative branch instructions became part of the discussion, but
since you asked...
 
Relative instructions (branches, loads, stores, etc.) do not use a segmented
value as the 20-bit instructions do, where the high order 8-bits are not
stored contiguously with the low order 12 bits. The relative address
instructions use a 16-bit (short) or 32-bit (long), signed binary value
indicating the number of half-words to be added to the address of the
relative address instruction to obtain the address of the data or branch
target address. It is really quite easy to support both short and long
relative addressing instructions with IFOX00 macros.
 
Shelby
 


  _____  

From: [hidden email] [mailto:[hidden email]]
Sent: Thursday, April 06, 2017 11:02 AM
To: [hidden email]
Subject: Re: [H390-MVS] Re: 'STY' instruction macro


 


Second question:


"Do the macros have an inherent 12-bit
limit, or do the macros generate 20-bit
offsets if assembled using ASMA90
on z/OS?"

the macros don't have any limit, but if you use an instruction
with a 12-bit-displacement as base to build a 20-bit displacement
instruction from it (example: STC, to build STY from it), you will
only get 12 bits on all platforms, because STC is limited to 12 bits.


This again has nothing to do with the macro processor (which is
a sort of special text processor, nothing more), but with the
ASSEMBLER and it's knowledge of instruction formats.


So it would be better to base "unknown" instructions with
20-bit displacements on other instructions with 20-bit displacements,
if there are any available (which of course will not be the case
with IFOX on MVS 3.8j).


BTW: this 12 to 20 bit expansion only works (IMO), because the
lower 12 bits of the 20 bit displacement are at exactly the same
place in the new instructions as the 12 bit displacements were
in the old instructions. IIRC, you have to take care of different
meaning of the displacements in some cases (when doing
some mappings, for example relative branches ... is that possible ???
Can relative branch instructions be constructed this way ???).


Kind regards

Bernd




Am 06.04.2017 um 19:47 schrieb Bernd Oppolzer:






Am 06.04.2017 um 19:10 schrieb [hidden email] [H390-MVS]:


 

---In [hidden email],  <mailto:tharminc@...> <tharminc@...> wrote
:

>> and produce identical object code. Of course
>> the 20-bit displacement restriction still exists
>> with the macros.

> I'm not sure what of all this is of real concern
> to you

I was surprised to see a mention of a
20-bit limit. I thought these macros
had a 12-bit limit, at least when using
IFOX on MVS 3.8j.

That is all. Nothing to do with GCCMVS.
GCCMVS is not my only interest. I'm
curious as to what the limits are if I
code an assembler LG/STG.

Do the macros have an inherent 12-bit
limit, or do the macros generate 20-bit
offsets if assembled using ASMA90
on z/OS?

BFN. Paul.



One of the tasks that the ASSEMBLER has to do:

it must translate symbolic (relocatable) names to base register /
displacement values
(depending on current USING definitions, base address and base register)

If the ASSEMBLER (for example IFOX) has its origins in a period of time
where only machine instructions with 12 bit displacements existed,
then this computation of displacements is limited to 12 bits; in other
words:
the internal tables of symbolic names only contain 12 bits to store the
displacement of a value, given a certain base register, because larger
displacement
don't make any sense; if a displacement is larger, the name will not be
accessible
by this base register, because there is no machine instruction where this
displacement
can be stored (as it is larger than 12 bits).

This is the 12 bit displacement limit; it comes from the layout of some
internal
tables of the ASSEMBLER, and it has nothing to do with the operating system
or the macro facility.

When the first machine instruction appeared in history, that had a 20 bit
displacement,
the internal tables of the ASSEMBLER which was modern at that time had to be

extended to support displacements larger than 12 bits; otherwise this
ASSEMBLER
would not have been able to support 20 bit displacements in the modern
instructions.  

HTH,
kind regards

Bernd