Hello - does anyone have a version of such a subroutine or program code?
Or are there some standard routines that I don't know about? I have a version using the Newton-Raphson procedure from "Principles of Assembler Programming for the IBM 370" by SD Stoddard. This works but only for perfect squares - for imperfect squares it works but is somewhat inaccurate. I'm no expert in using IBM floating point and am struggling a bit. And so far have not found much useful help from Google. This is not for any project but only for my personal education........ Appreciate any pointers. Best regards Bill Turner (from South Africa) |
On 5/22/17 9:31 AM, William D ASM [hidden email] [H390-MVS] wrote:
> Hello - does anyone have a version of such a subroutine or program code? > Or are there some standard routines that I don't know about? I don't know whether the attached is accurate enough for you. It was concocted from a public-domain version of ForTran's DSQRT. It's in plain ASCII, as transferred with IND$FIL Gerhard Postpischil Bradford, VT --- This email has been checked for viruses by AVG. http://www.avg.com |
The Stanford Pascal compiler uses DSQRT from SYS1.FORTLIB, too.
The square roots from 1 to 20 computed with DSQRT (on VM): prun testsqrt FILEDEF INPUT TERM ( RECFM V LRECL 255 FILEDEF OUTPUT TERM ( RECFM V FILEDEF PASTRACE TERM ( RECFM F EXEC PASRUN TESTSQRT the sqrt of 1 is 1.0000000000000 the sqrt of 2 is 1.4142135623732 the sqrt of 3 is 1.7320508075690 the sqrt of 4 is 2.0000000000001 the sqrt of 5 is 2.2360679775000 the sqrt of 6 is 2.4494897427834 the sqrt of 7 is 2.6457513110648 the sqrt of 8 is 2.8284271247464 the sqrt of 9 is 3.0000000000002 the sqrt of 10 is 3.1622776601687 the sqrt of 11 is 3.3166247903557 the sqrt of 12 is 3.4641016151381 the sqrt of 13 is 3.6055512754643 the sqrt of 14 is 3.7416573867742 the sqrt of 15 is 3.8729833462077 the sqrt of 16 is 4.0000000000003 the sqrt of 17 is 4.1231056256181 the sqrt of 18 is 4.2426406871197 the sqrt of 19 is 4.3588989435411 the sqrt of 20 is 4.4721359550000 Ready; T=0.05/0.14 17:19:32 and on Windows: the sqrt of 1 is 1.0000000000000 the sqrt of 2 is 1.4142135623731 the sqrt of 3 is 1.7320508075689 the sqrt of 4 is 2.0000000000000 the sqrt of 5 is 2.2360679774998 the sqrt of 6 is 2.4494897427832 the sqrt of 7 is 2.6457513110646 the sqrt of 8 is 2.8284271247462 the sqrt of 9 is 3.0000000000000 the sqrt of 10 is 3.1622776601684 the sqrt of 11 is 3.3166247903554 the sqrt of 12 is 3.4641016151378 the sqrt of 13 is 3.6055512754640 the sqrt of 14 is 3.7416573867739 the sqrt of 15 is 3.8729833462074 the sqrt of 16 is 4.0000000000000 the sqrt of 17 is 4.1231056256177 the sqrt of 18 is 4.2426406871193 the sqrt of 19 is 4.3588989435407 the sqrt of 20 is 4.4721359549996 you may notice the differences, different number representations and rounding techniques (I guess, the difference may result from the rounding before output, not from the computation itself; the rounding is done - for example - to make sure to get a numver slightly above 3 for the square root of 9 ... and not 2.999999999999x). The Pascal program: program TESTSQRT ( OUTPUT ) ; var I : INTEGER ; R : REAL ; begin (* HAUPTPROGRAMM *) for I := 1 to 20 do begin R := I ; WRITELN ( 'the sqrt of ' , I : 4 , ' is ' , SQRT ( R ) : 15 : 13 ) ; end (* for *) end (* HAUPTPROGRAMM *) . When trying this on MVS, I discovered that the linker step has a problem with the different record formats and record lenghts of the SYSLIB datasets: //SYSLIB DD DISP=SHR,DSN=&HLQ..RUNTIME.TEXT // DD DISP=SHR,DSN=&HLQ..COMPILER.TEXT // DD DISP=SHR,DSN=SYS1.FORTLIB ... length error, because SYS1.FORTLIB is U 13xxx and the other libraries are FB 80 ... I didn't realize this until now, I have to find another solution for this. Kind regards Bernd Am 22.05.2017 um 16:23 schrieb Gerhard Postpischil [hidden email] [H390-MVS]: > [Attachment(s) <#TopText> from Gerhard Postpischil included below] > > On 5/22/17 9:31 AM, William D ASM [hidden email] [H390-MVS] wrote: > > Hello - does anyone have a version of such a subroutine or program code? > > Or are there some standard routines that I don't know about? > I don't know whether the attached is accurate enough for you. It was > concocted from a public-domain version of ForTran's DSQRT. > > It's in plain ASCII, as transferred with IND$FIL > > Gerhard Postpischil > Bradford, VT > > --- > This email has been checked for viruses by AVG. > http://www.avg.com > > |
On Mon, 22 May 2017 17:29:38 +0200, "Bernd Oppolzer
[hidden email] [H390-MVS]" <[hidden email]> wrote: > The Stanford Pascal compiler uses DSQRT from SYS1.FORTLIB, too. > > The square roots from 1 to 20 computed with DSQRT (on VM): > > prun testsqrt > FILEDEF INPUT TERM ( RECFM V LRECL 255 > FILEDEF OUTPUT TERM ( RECFM V > FILEDEF PASTRACE TERM ( RECFM F ===============8<----------------------------- > > you may notice the differences, > different number representations and rounding techniques > (I guess, the difference may result from the rounding before > output, not from the computation itself; the rounding is done > - for example - to make sure to get a numver slightly above 3 for > the square root of 9 ... and not 2.999999999999x). > There is an important difference in floating point representation. In mainframe the floating point uses a power of 16 to normalize the represented number, in IEEE platforms the normalization is done in a power of 2. This makes the discretization of number space different, leading to different rounding. But the final results must be close, whatever this means. ;) ====================8<------------------------ > > When trying this on MVS, I discovered that the linker step has > a problem with the different record formats and record lenghts > of the SYSLIB datasets: > > //SYSLIB DD DISP=SHR,DSN=&HLQ..RUNTIME.TEXT > // DD DISP=SHR,DSN=&HLQ..COMPILER.TEXT > // DD DISP=SHR,DSN=SYS1.FORTLIB > > ... length error, because SYS1.FORTLIB is U 13xxx and the > other libraries are FB 80 ... > > I didn't realize this until now, I have to find another solution for > this. If I recall correctly, in MVS the linker had a problem with concatenation of datasets of different block sizes. Those libraries that are usually record format U allocated, the longest block size must be after the shorter block sizes in concatenation. Regards. Roxo -- ---------------- Non luctari, ludare -------------------+ WYSIWYG Fernando M. Roxo da Motta <[hidden email]> | Editor? Except where explicitly stated I speak on my own behalf.| VI !! ( Usuário Linux registrado #39505 ) | I see text, ------------ Quis custodiet ipsos custodes?-------------+ I get text! |
On 5/22/17 12:07 PM, 'Fernando M. Roxo da Motta' [hidden email] [H390-MVS]
wrote: > If I recall correctly, in MVS the linker had a problem with > concatenation of datasets of different block sizes. Those libraries > that are usually record format U allocated, the longest block size must > be after the shorter block sizes in concatenation. The Linkage Editor and Loader Programmer's Guide explicitly documents the restrictions: SYSLIB may specify concatenation of RECFM U, any blocksize, or a concatenation of card format data (max block size 3120 unless zapped). I usually use SYSLIB for load modules and partially resolved subroutines, and a separate data set for object and control cards. Gerhard Postpischil Bradford, VT --- This email has been checked for viruses by AVG. http://www.avg.com |
In reply to this post by Hercules390 - Mvs mailing list
On 22/05/2017 16:23, Gerhard Postpischil [hidden email] [H390-MVS]
wrote: > [Attachment(s) <#TopText> from Gerhard Postpischil included below] > > On 5/22/17 9:31 AM, William D ASM [hidden email] [H390-MVS] wrote: > > Hello - does anyone have a version of such a subroutine or program code? > > Or are there some standard routines that I don't know about? > I don't know whether the attached is accurate enough for you. It was > concocted from a public-domain version of ForTran's DSQRT. > > It's in plain ASCII, as transferred with IND$FIL > > Gerhard Postpischil > Bradford, VT > > --- > This email has been checked for viruses by AVG. > http://www.avg.com > > > > Attachment(s) from Gerhard Postpischil | View attachments on the web > <https://groups.yahoo.com/neo/groups/H390-MVS/attachments/1071049626;_ylc=X3oDMTJxZ2ZqOTFoBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNhdHRhY2htZW50BHNsawN2aWV3T25XZWIEc3RpbWUDMTQ5NTQ2Mjk5NQ--> > > 1 of 1 File(s) > > SUBSQRT.ASM > <https://xa.yimg.com/kq/groups/2587966/1391384812/name/SUBSQRT%2EASM> > ------------------------------------------------------------------------ > Posted by: Gerhard Postpischil <[hidden email]> With regard to Bernd's post, the error I am seeing is much larger than might be due to rounding. the logic error in my version is something that might become a bit more obvious given a bit more time and experience with floating point (I hope). I am trying to avoid IEEE FP at the moment - I'm aware of the difference between it and IBM's implementation. Many thanks for the responses and regards to all Bill Turner (South Africa) |
The source to WATFIV on the VM six pack has the attached..
Dave G4UGM From: [hidden email] [mailto:[hidden email]] Sent: 23 May 2017 05:51 To: [hidden email] Subject: Re: [H390-MVS] Assembler F square root subroutine On 22/05/2017 16:23, Gerhard Postpischil [hidden email] <mailto:[hidden email]> [H390-MVS] wrote: On 5/22/17 9:31 AM, William D ASM [hidden email] <mailto:[hidden email]> [H390-MVS] wrote: > Hello - does anyone have a version of such a subroutine or program code? > Or are there some standard routines that I don't know about? I don't know whether the attached is accurate enough for you. It was concocted from a public-domain version of ForTran's DSQRT. It's in plain ASCII, as transferred with IND$FIL Gerhard Postpischil Bradford, VT --- This email has been checked for viruses by AVG. http://www.avg.com Attachment(s) from Gerhard Postpischil | <https://groups.yahoo.com/neo/groups/H390-MVS/attachments/1071049626;_ylc=X3oDMTJxZ2ZqOTFoBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNhdHRhY2htZW50BHNsawN2aWV3T25XZWIEc3RpbWUDMTQ5NTQ2Mjk5NQ--> View attachments on the web 1 of 1 File(s) <http://l.yimg.com/kq/static/images/yg/img/doc/generic16x16.gif> <https://xa.yimg.com/kq/groups/2587966/1391384812/name/SUBSQRT%2EASM> SUBSQRT.ASM _____ Posted by: Gerhard Postpischil <mailto:[hidden email]> <[hidden email]> Many thanks Gerhard - will give it a try. With regard to Bernd's post, the error I am seeing is much larger than might be due to rounding. the logic error in my version is something that might become a bit more obvious given a bit more time and experience with floating point (I hope). I am trying to avoid IEEE FP at the moment - I'm aware of the difference between it and IBM's implementation. Many thanks for the responses and regards to all Bill Turner (South Africa) |
In reply to this post by Hercules390 - Mvs mailing list
On 22 May 2017 at 09:31, William D ASM [hidden email] wrote:
> Hello - does anyone have a version of such a subroutine or program code? > Or are there some standard routines that I don't know about? Depending on the level of [emulated] hardware you are running on, the Square Root instructions may be available to you. How an old operating system will handle a Square Root exception (program check 1D) is an interesting question. On z/OS this turns into an abend S0E0-1D. Tony H. |
On 23/05/2017 19:02, Tony Harminc [hidden email] [H390-MVS] wrote:
> > On 22 May 2017 at 09:31, William D ASM [hidden email] wrote: > > Hello - does anyone have a version of such a subroutine or program code? > > Or are there some standard routines that I don't know about? > > Depending on the level of [emulated] hardware you are running on, the > Square Root instructions may be available to you. How an old operating > system will handle a Square Root exception (program check 1D) is an > interesting question. On z/OS this turns into an abend S0E0-1D. > > Tony H. > > > ------------------------------------------------------------------------ > Posted by: Tony Harminc <[hidden email]> else - what do the square root instructions look like - ie which versions of POPS? I would like to look at that but this exercise was only for my personal satisfaction. I don't actually need it but any progress would be welcome. Many thanks Tony Bill Turner (South Africa) |
On 5/24/17 12:56 AM, William D ASM [hidden email] [H390-MVS] wrote:
> Well it is CPUMODEL 3033 in the config. Quite willing to try something > else - what do the square root instructions look like - ie which > versions of POPS? AFAIK, Hercules doesn't use the CPU model for anything but the STIDP instruction. What instructions are available depend on the mode (370, 390, zOS) YOU RUN IN. Gerhard Postpischil Bradford, VT --- This email has been checked for viruses by AVG. http://www.avg.com |
On 24/05/2017 08:19, Gerhard Postpischil [hidden email] [H390-MVS]
wrote: > > On 5/24/17 12:56 AM, William D ASM [hidden email] [H390-MVS] wrote: > > Well it is CPUMODEL 3033 in the config. Quite willing to try something > > else - what do the square root instructions look like - ie which > > versions of POPS? > > AFAIK, Hercules doesn't use the CPU model for anything but the STIDP > instruction. What instructions are available depend on the mode (370, > 390, zOS) YOU RUN IN. > > Gerhard Postpischil > Bradford, VT > provided something I was not aware of - the square root instruction is provided in the mathematical assists hardware provided in some models for various systems from the 370 up, as I understand it from the manual :- SA22-7094-1_System_370_Mathematical_Assists_Dec84 manual It is 1984 but it reads from the preface :- The instructions are valid in any archi- tectural mode (System/370, ECPS:VSE, or 370-XA) available on a model equipped with the corresponding mathematical- assist facility. I would not mind trying it but I suspect Hercules might not like it. In any case, I'm more interested in learning how to do it the hard way in assembler code. But thanks for the thought. Regards Bill Turner (South Africa) |
Hi Bill,
If you are using the Hercules provided by TK4- Update 08, the square root instructions are available if you load the Hercules s37x module (see ldmod command in Hercules doc). The following operations are supported: SQD SQDB SQDBR SQDR SQE SQEB SQEBR SQER SQXBR SQXR Macros to generate the appropriate opcodes are provided in SYS2.SXMACLIB (again, provided with TK4- Update 08). Shelby _____ From: [hidden email] [mailto:[hidden email]] Sent: Wednesday, May 24, 2017 4:03 AM To: [hidden email] Subject: Re: [H390-MVS] Assembler F square root subroutine On 24/05/2017 08:19, Gerhard Postpischil [hidden email] [H390-MVS] wrote: On 5/24/17 12:56 AM, William D ASM [hidden email] [H390-MVS] wrote: > Well it is CPUMODEL 3033 in the config. Quite willing to try something > else - what do the square root instructions look like - ie which > versions of POPS? AFAIK, Hercules doesn't use the CPU model for anything but the STIDP instruction. What instructions are available depend on the mode (370, 390, zOS) YOU RUN IN. Gerhard Postpischil Bradford, VT Well no - thanks to the prodding from yourself, a little googling provided something I was not aware of - the square root instruction is provided in the mathematical assists hardware provided in some models for various systems from the 370 up, as I understand it from the manual :- SA22-7094-1_System_370_Mathematical_Assists_Dec84 manual It is 1984 but it reads from the preface :- The instructions are valid in any archi- tectural mode (System/370, ECPS:VSE, or 370-XA) available on a model equipped with the corresponding mathematical- assist facility. I would not mind trying it but I suspect Hercules might not like it. In any case, I'm more interested in learning how to do it the hard way in assembler code. But thanks for the thought. Regards Bill Turner (South Africa) |
On 24 May 2017 at 15:33, 'Shelby Beach' [hidden email] wrote:
> If you are using the Hercules provided by TK4- Update 08, the square root > instructions are available if you load the Hercules s37x module (see ldmod > command in Hercules doc). The following operations are supported: > > SQD > SQDB > SQDBR > SQDR > SQE > SQEB > SQEBR > SQER > SQXBR > SQXR > > Macros to generate the appropriate opcodes are provided in SYS2.SXMACLIB > (again, provided with TK4- Update 08). > Which prompts me to wonder again what MVS 3.8 will do when it encounters a Square Root exception. OK - tried it, and I quite reasonably get a C0D abend - "An unexpected error occurred." Good choice... And more generally what Hercules does when a Data eXeption Code (DXC) is required by ESA or zArch to be stored at location 147 (X'93') which in S/370 is part of the Translation Exception Address (TEA). Hmmm... I suppose they can share that spot, since there is no overlap between program checks that store the TEA and those that store the DXC. And actually the low byte of the TEA is probably unused in all cases on S/370, though it will be written as zero. Tony H. |
In reply to this post by Hercules390 - Mvs mailing list
Can you link the OBJ module under Hercules from z390 zHLASM and test it James Francis Cray ________________________________ From: [hidden email] <[hidden email]> on behalf of Gerhard Postpischil [hidden email] [H390-MVS] <[hidden email]> Sent: Monday, May 22, 2017 10:23 AM To: [hidden email] Subject: Re: [H390-MVS] Assembler F square root subroutine [1 Attachment] [Attachment(s) from Gerhard Postpischil included below] On 5/22/17 9:31 AM, William D ASM [hidden email] [H390-MVS] wrote: > Hello - does anyone have a version of such a subroutine or program code? > Or are there some standard routines that I don't know about? I don't know whether the attached is accurate enough for you. It was concocted from a public-domain version of ForTran's DSQRT. It's in plain ASCII, as transferred with IND$FIL Gerhard Postpischil Bradford, VT --- This email has been checked for viruses by AVG. http://www.avg.com |
In reply to this post by Hercules390 - Mvs mailing list
On 24/05/2017 21:33, 'Shelby Beach' [hidden email] [H390-MVS]
wrote: > > Hi Bill, > If you are using the Hercules provided by TK4- Update 08, the square > root instructions are available if you load the Hercules s37x module > (see ldmod command in Hercules doc). The following operations are > supported: > SQD > SQDB > SQDBR > SQDR > SQE > SQEB > SQEBR > SQER > SQXBR > SQXR > > Macros to generate the appropriate opcodes are provided in > SYS2.SXMACLIB (again, provided with TK4- Update 08). > Shelby I'm more interested in learning the intricacies of assembler level floating point programming than in actually obtaining square roots but I will try it. Always willing to learn new tricks..... Of course, there does not seem to be any real world benefit arising from my new found skills ;-) but having a lot of fun doing it. Again thanks to yourself and all the others who have taken the trouble to respond on the subject. Greatly appreciated. Regards Bill Turner ( South Africa) |
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <bturnersa@...> wrote :
> Hello - does anyone have a version > of such a subroutine or program code? sqrt() is a standard function in C90. I just tried this program: C:\mvs380_work\cprog>type dosqrt.c #include <stdio.h> #include <math.h> int main(void) { printf("sqrt of 10 is %f\n", sqrt(10.0)); return (0); } C:\mvs380_work\cprog> on MVS and it worked fine: sqrt of 10 is 3.162278 I verified the result on the PC: C:\mvs380_work\cprog>zcalc 10**0.5 Calculated Value is 3.162278 Thank you for using the calculator C:\mvs380_work\cprog> The C code compiles into MVS assembler if you want to read that. Depending on your system you may find the sqrt() code (and the code it calls) in GCC.S2(MATH). BFN. Paul. |
Good idea.
Can/Will you somehow distribute the MVS assembler code? Or a snippet? On Fri, Jun 2, 2017 at 11:11 PM, [hidden email] [H390-MVS] < [hidden email]> wrote: > > > ---In [hidden email], <bturnersa@...> wrote : > > > Hello - does anyone have a version > > of such a subroutine or program code? > > sqrt() is a standard function in C90. > > I just tried this program: > > C:\mvs380_work\cprog>type dosqrt.c > #include <stdio.h> > #include <math.h> > int main(void) > { > printf("sqrt of 10 is %f\n", sqrt(10.0)); > return (0); > } > C:\mvs380_work\cprog> > > on MVS and it worked fine: > > sqrt of 10 is 3.162278 > > > I verified the result on the PC: > > C:\mvs380_work\cprog>zcalc 10**0.5 > Calculated Value is 3.162278 > Thank you for using the calculator > C:\mvs380_work\cprog> > > > The C code compiles into MVS assembler > if you want to read that. Depending on > your system you may find the sqrt() > code (and the code it calls) in > GCC.S2(MATH). > > BFN. Paul. > > > -- GnuPG/PGP key: 0xB07F9AAE +-----------------------------------------------------------------------------------------------------+ | 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510 | | 58209 74944[59230 78164]06286 20899 86280 +----------------------------------| | 34825 34211 70679*82148 08651 32823 06647 | May the spirit | | 09384 46095 50582 23172 53594 08128 48111 | of π spread | | 74502 84102 70193 85211 05559 64462 29489 | around the world. | | 54930 38196 44288 10975 66593 34461 28475 | PI VOBISCUM! | | 38196 44288 10975 66593 34461 28475 64823 +---------------------------------| | 37867 83165 27120 19091 45648 56692 34603 48610 45432 6648... | +----------------------------------------------------------------------------------------------------+ |
In reply to this post by Hercules390 - Mvs mailing list
On 03/06/2017 05:11, [hidden email] [H390-MVS] wrote:
> ---In [hidden email], <bturnersa@...> wrote : > > > Hello - does anyone have a version > > of such a subroutine or program code? > > sqrt() is a standard function in C90. > > I just tried this program: > > C:\mvs380_work\cprog>type dosqrt.c > #include <stdio.h> > #include <math.h> > int main(void) > { > printf("sqrt of 10 is %f\n", sqrt(10.0)); > return (0); > } > C:\mvs380_work\cprog> > > on MVS and it worked fine: square root but to do it using 370 assembler floating point code. I'm getting there but the result is a little out - for eg a sqrt of 51830 should give 227.6620302 (according to my Sharp calculator) but I get 227.61.... something. Still, am getting closer. It is just a learning exercise, I was intrigued by a comment in Professor Edward Bosworth's online text books that such floating point code had not been written for a long time and certainly, I have not been able to locate any other than the dis-assembled Fortran/C modules. So we persevere. What do you do for relaxation? ;-) Many thanks again and regards to all. Bill Turner (South Africa) |
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <stercor@...> wrote :
>> GCC.S2(MATH). > Good idea. > Can/Will you somehow distribute the MVS assembler code? > Or a snippet? The code above comes as part of the GCCMVS distribution, which you can find here: https://sourceforge.net/projects/gccmvs/files/GCCMVS/GCC%203.2.3%20MVS%208.5/ If you are running MVS/380 or TK4- then I think you will find that it is already installed on your system. If you don't wish to install GCCMVS, I can instead send you a dev version of math.s (assembler generated from C) if you like. BFN. Paul. |
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <bturnersa@...> wrote :
> sqrt() is a standard function in C90. > Paul - many thanks for the interest but > my main aim is not just to get a square > root but to do it using 370 assembler > floating point code. I think you might have misunderstood my message. The referenced SQRT code *is* *entirely* S/370 assembler floating point code. It's true that the S/370 assembler was generated from C, but who cares? Or do you care that the assembler code doesn't have any comments in it because it was generated? Surely it is better to maintain and read the original C code instead of the generated assembler? But either way works regardless. :-) BFN. Paul. |
Free forum by Nabble | Edit this page |