Converting assembler code from APL+DOS to APL+Win

[Don Wiss]

In 1994 I hired Jim Weigang to write a piece of assembler to speed up an often used loop. I recall him saying something about all I had to do for Windows was to change the first number.

Looking at the assembler vectors between DOS and Win (in the various vendor supplied routines) I see the change in the first number, but much else of the vectors is also different.

I found this text file from Jim. Line [8] is broken, so I simply set it to the second number. But I have no idea what the argument is to this.

     {del} Z{<-}F32TO64 C;T
[1]    @Converts IEEE 32-bit reals {omega} to 64-bit reals
[2]    @ The argument is a character vector containing the 32-bit reals, in
[3]    @   standard Intel byte-reversed order (i.e., 1{take}C holds the low {+
   +}8 bits
[4]    @   of the first number).  The result is a numeric vector.
[5]    @ This program can be used on either APL*PLUS II/386 or III/Windows
[6]    @
[7]    T{<-}0 858915563 {neg}1992758141 1714562148 35931273 610044262 {neg}{+
   +}957576422 {neg}972945595 {neg}972939451 {neg}973076923 1711283781 {+
   +}1711282360 1711293833 1712866697 3163591 28861952 15224832 1476395008 {+
   +}{neg}1132953554 74799184 82561229 1009014015 841247883 {neg}949558309 {+
   +}{neg}51643 1714847197 2134271361 1717990656 3556807 914217216 {+
   +}912621926 {neg}2090467265 1967076989 409832784 178278 59472 777519104 {+
   +}{neg}9324416 1481703423 {neg}926088075 1425999083 628243492 841247883 {+
   +}1867136 2105544565 292880669 606619019 {neg}351898365 {neg}352210148 {+
   +}{neg}352079086 {neg}351948018 {neg}351816950 {neg}351751418 856470274 {+
   +}{neg}339506496 71681624 88458755 541428481 {neg}1996298047 1166610501 {+
   +}122013192 7179521 243814 59472 777519104 {neg}16664448 1481703423 {neg}{+
   +}926088075 1425999083 {neg}1183695836 841247883 {neg}1960544885 {+
   +}1300958333 {neg}653466872 74878214 2139955165 871686664 {neg}{+
   +}2082284608 12794052 951127 120349
[8]    T[#IO]{<-}(1345730611 2000042035)['3/'{iota}#SYSID[#IO+12]]
[9]    {->}(T{<-}''{rho}(#STPTR'Z C')#CALL T){drop}0
[10]   #ERROR(3 5 7 8 12{iota}T){pick}'LENGTH ERROR' 'RANK ERROR' 'VALUE {+
   +}ERROR' 'WS FULL' 'MATH PROCESSOR ABSENT' 'DOMAIN ERROR'
[11]   @ Copyright 1995 by Jim Weigang
     {del}

The loop in the assembler code is:

   L1:
    FLD DWORD PTR [ESI]     ; load C[i]
    LEA ESI,[ESI+4]         ; point to next element
    FSTP QWORD PTR [EDI]    ; store into Z[i]
    LEA EDI,[EDI+8]         ; point to next element
    LOOP L1

[Davin Church]

I've never seen this routine, but apparently it needs input coming in from some external source where the data is defined as a "short float".  Since APL doesn't have any way for us to convert this to a usable form and it obviously isn't doing it under the covers, then the only thing that makes sense as an argument here is to either pass in a pointer to a 32-bit float or to pass in the 32-bit float as a 4-byte vector of bytes (in character form).  It may be possible to disassemble the whole program and figure it out from scratch if there's no other way.

[Don Wiss]

Thanks for replying. Roy also explained it to me. I then remembered why it existed. I had a friend (now disappeared like Jim Weigang) that helped me convert the bond data of a competitor's program to my format. The friend could read the Basic data format. Nibble, by nibble. Being able to import the competitor's data was indispensable to BondCalc's success.