Re: *-*
The origin was explained to us as I described. As far as how back it goes
prior the timeframe I detailed, I am unable to say.
The instructor was a PhD, so I would not categorize him as uninformed.
In addition to the S/360 that we had at the university, we had an IBM 1620,
an IBM 709x (I don't recall the exact model), and numerous DEC machines.
John P. Baker
Software Developer
-Original Message-
From: IBM Mainframe Assembler List On
Behalf Of Seymour J Metz
Sent: Friday, May 1, 2020 12:07 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: *-*
Actually, you don't remember the origin, you remember an uninformed
instructor feeding you an invented etymology. The usage precedes the S/360
by years; it dates to the 709 if not before. See, e.g., the FAP manual on
bitsavers.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
behalf of jba...@ngssallc.com [jba...@ngssallc.com]
Sent: Thursday, April 30, 2020 10:14 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: *-*
I must really be getting old, because I actually remember the origin of the
convention.
The convention of "*-*" in a length field was based upon an interpretation
of the expression "{address-of-last-byte}-{address-of-first-byte}" which
calculates the "machine length" of the field, which is one less than the
actual length of the field.
When moving a variable length field, the instruction had to be "EX(ecuted)",
so the programmer likely did not know the value of "{address-of-last-byte}"
at assembly time and in many cases did not know the value of
"{address-of-first-byte}" at assembly time, so the programmer simply
replaced each unknown with "*" and voila, we had "*-*".
We discussed this in assembler programming class some 47 years ago.
John P. Baker
Software Developer
-Original Message-
From: IBM Mainframe Assembler List On
Behalf Of robi...@dodo.com.au
Sent: Thursday, April 30, 2020 4:46 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: *-*
On 2020-04-30 18:15, Martin Ward wrote:
> On 30/04/2020 03:48, robi...@dodo.com.au wrote:
>>
>> What's wrong with a comment?
>
> It *is* a comment (in the broader sense).
No it isn't. *-* doesn't explain anything.
If it did, people wouldn't be asking what on earth is it.
A comment that explains that the length is planted by some other instruction
or whatever else is it, is the only way to document it.
Re: *-*
I must really be getting old, because I actually remember the origin of the
convention.
The convention of "*-*" in a length field was based upon an interpretation
of the expression "{address-of-last-byte}-{address-of-first-byte}" which
calculates the "machine length" of the field, which is one less than the
actual length of the field.
When moving a variable length field, the instruction had to be "EX(ecuted)",
so the programmer likely did not know the value of "{address-of-last-byte}"
at assembly time and in many cases did not know the value of
"{address-of-first-byte}" at assembly time, so the programmer simply
replaced each unknown with "*" and voila, we had "*-*".
We discussed this in assembler programming class some 47 years ago.
John P. Baker
Software Developer
-Original Message-
From: IBM Mainframe Assembler List On
Behalf Of robi...@dodo.com.au
Sent: Thursday, April 30, 2020 4:46 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: *-*
On 2020-04-30 18:15, Martin Ward wrote:
> On 30/04/2020 03:48, robi...@dodo.com.au wrote:
>>
>> What's wrong with a comment?
>
> It *is* a comment (in the broader sense).
No it isn't. *-* doesn't explain anything.
If it did, people wouldn't be asking what on earth is it.
A comment that explains that the length is planted by some other instruction
or whatever else is it, is the only way to document it.
Re: EQU * considered harmful
Gary, I discontinued the use of - label DS 0H in lieu of - label DC 0H'0' long ago. As best as I can recall, there was a bug identified (subsequently corrected (?)) where the buffer into which code was assembled was not always initialized to zeroes, and it was possible to have memory locations skipped over by virtue of alignment issues contain random data. The use of " DC " in lieu of " DS " ensures that memory locations skipped over by virtue of alignment are initialized to zeroes. John P. Baker -Original Message- From: IBM Mainframe Assembler List On Behalf Of Gary Weinhold Sent: Wednesday, August 1, 2018 2:40 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EQU * considered harmful To avoid the problem Dan illustrates but retain the advantages Charles cites of not labeling specific instructions, we use label DS 0H instead of label EQU * But i think some of the point of the original post was lost, since the question was whether label EQU* was ever beneficial, where the "*" indicates current location rather than meaning generically any value. On 2018-08-01 2:23 PM, Dan Greiner wrote: > I too disagree (rather strongly). > > As an example, consider where EQU is used to give names to bits of a field in > memory. > > FLAGSDSX > F_OPEN EQU X'80' > F_CLOSE EQU X'40' > F_FUBAR EQU X'20' > ... > TMFLAGS,F_FUBAR > JOTOTALLY_HOSED > > Furthermore, you can assign a "length" to each bit, and use that as an offset > in the field, e.g: > > FLAGSDSXL4 > F_OPEN EQU X'80',0 > F_CLOSE EQU X'40',0 > F_FUBAR EQU X'02',3 > ... > TMFLAGS+L'F_FUBAR,F_FUBAR > > (apologies if the syntax is not precise ... I'm doing this from memory at > home). > > As to Charles' comment about using EQU as a branch target, I'm a little bit > less comfortable. If — by chance or accident — there happens to be code > before the EQU that knocks the location off a halfword boundary, this could > spell trouble. E.g: > > LA 7,ITS_ON > TMBYTE,BIT > BCR X'01',7 > ... > other instructions > HI_MOM DCC'Hello' > ITS_ON EQU * > > Since the constant "Hello" is 5 bytes long, this knocks the label ITS_ON onto > an odd boundary. If the branch had been directly to the location (as opposed > to BCR), HLASM would have flagged an error. But in this case, the error may > go undetected until execution — at which point the hardware will slap you > with a PIC-0006 (PIC-0006). Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone +1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
