Color me ignorant, but if I’m reading this correctly, in your fist paragraph, you use signed halfwords but in the second paragraph, it’s more like signed fullwords. So C’FU’ would be X’C6E4’or -14,620. As such, wouldn’t you want to subtract X’8000’?
I’m looking at implementing MVHUI (move halfword unsigned) and came up with this construct (have not tested yet): &raw SETA &OP2 .compute Anop , &neg SetB (&raw gt 32767) Aif (not &neg).setconst &raw SetA (&raw or X’7FFF’) .setconst Anop , MVHHI &OP1,&raw Aif (not &neg).mend OIY &OP1,X’80’ .mend Anop , *Mark Hammack* [email protected] 214-478-0955 (c) On Mon, Aug 25, 2025 at 11:52 AM Jonathan Scott < [email protected]> wrote: > Halfword signed immediate operands outside the range -32768 to 32767 are > only tolerated by HLASM when normal checking is disabled using the options > TYPECHECK(NOSIGNED) or, worse, TYPECHECK(NOMAGNITUDE). As that can lead to > accidents, it is not recommended. > > This applies to C'FU', C'LL' and 48000 in the following examples. They can > all be made valid by subtracting X'10000', and it is possible to write an > expression that will automatically apply that correction when necessary, > even for a symbolic value, so it is possible to write a macro which is an > unsigned equivalent of MVHHI, provided that the value does not exceed > 65535. > > And truncation of 65537 to 1 for an immediate operand is only tolerated by > HLASM when TYPECHECK(NOMAGNITUDE) is specified. > > Of course, there is no such check on what a compiler can generate in > binary; > if it chooses to list generated instructions as assembler which contains > values that are technically out of range, that won't affect the results. > > I agree a shift operator in assembler expressions would be useful (along > with some other functions and operators). It was still on the list when I > retired, mainly because operators are converted to 1-byte internal codes > and > there were no free values left in the encoding scheme, so it would have > needed a major design change. Shift functions are available in the macro > language, but can only be used if the value is known at macro time. > > Jonathan Scott > > -----Original Message----- > From: IBM Mainframe Assembler List <[email protected]> On > Behalf Of Ngan, Robert (DXC Luxoft) > Sent: 25 August 2025 17:20 > To: [email protected] > Subject: Re: Execute-Type Instructions > > You would use MVHI where appropriate, but the MVHI immediate operand is a > SIGNED halfword, so: > > MVC XL4a,=C'FULL' > > would be coded as: > > MVHHI XL4a+0,C'FU' > MVHHI XL4a+2,C'LL' > > And: > > MVC XL4b,=F'48000' > > would be coded as: > > MVHHI XL4a+0,0 > MVHHI XL4a+2,48000 > > And: > > MVC XL4b,=F'65537' > > would be coded as: > > MVHHI XL4a+0,65537>>16 i.e. 1 > MVHHI XL4a+2,65537 which HLASM conveniently > truncates to 1 for us > > There no actual SHIFT operator, so (in general) this is implemented as an > arithmetic expression. > > Robert Ngan > DXC Lusoft > > -----Original Message----- > From: IBM Mainframe Assembler List <[email protected]> On > Behalf Of João Reginato > Sent: Saturday, August 23, 2025 07:53 > To: [email protected] > Subject: RES: Execute-Type Instructions > Importance: Low > > [Algumas pessoas que receberam esta mensagem geralmente não receberão > emails > de [email protected]. Saiba por que isso é > importante em https://aka.ms/LearnAboutSenderIdentification ] > > Why not just one MVHI instead of two MVHHI? > > -----Mensagem original----- > De: IBM Mainframe Assembler List <[email protected]> Em nome > de Jon Perryman Enviada em: sábado, 23 de agosto de 2025 00:12 > Para: [email protected] > Assunto: Re: Execute-Type Instructions > > On Fri, 22 Aug 2025 17:00:33 +0000, Ngan, Robert <[email protected]> > wrote: > > >I noticed the COBOL compile generated two MVHHI's to set a fullword > >field with a constant value, but did an MVC with an 8-byte constant > >when setting two adjacent fullwords. > > This makes sense because data is in the pipeline instead of moving from L1. > > With inline constants, you eliminated the extra fetch from storage. Ask > yourself if it's worth the effort to eliminate the extra L1 access. You're > running C, Java, Python and ??? where you can save a few dollars instead of > a few penniess. >
