OEYO8729@TREARN.BITNET (Cem TURGAY) (02/20/91)
Hello, Is there anybody out there ? I can't hear anything from you, hey assembly-ers ! Last time I asked for HX entry of CMS but no one reply to me. Where are you ? Did you leave the assembler lists ? Now, I have a problem with to write double word numbers to screen in assembly ? Do you have any example or macro about floating to character conversion ? Would you please help to me. Thanks. Cem Turgay PROHVK32@TREARN, OEYO8729@TREARN
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (02/21/91)
OEYO8729@TREARN.BITNET (Cem TURGAY) writes: >Hello, Hello Cem in Turkey. >Is there anybody out there ? Yes, at least right now there is. >I can't hear anything from you, hey assembly-ers ! >Last time I asked for HX entry of CMS but no one reply to me. >Where are you ? Did you leave the assembler lists ? I can't say for others but it has been a while since I read this. I am reading it via USENET NEWS, not as a mailing list. Hopefully my postings make it back to the mailing list. >Now, I have a problem with to write double word numbers to screen >in assembly ? Do you have any example or macro about floating to >character conversion ? Would you please help to me. Thanks. There are a number of different approaches to doing this. They vary in how accurate the decimal digits are to the binary floating point number. There are some floating point numbers that can require as many at 56 digits of the fractional part to accurately represent in decimal. The reason for this is because each bit is half the value of the previous one in the fraction. Binary Decimal 1.0000 1.0000 0.1000 0.5000 0.0100 0.2500 0.0010 0.1250 0.0001 0.0625 1.1111 1.9375 If the numbers are WHOLE numbers you can convert them to INTEGER and convert them to decimal quickly and accurately. I have a macro that generates an assembler function to do the conversion of signed or unsigned (different ones) double INTEGERS to decimals. One possible approach to converting FLOATING point numbers to decimal is to construct a table of powers of 10 in floating point. Starting with the number to be converted, search the table from the highest value until you find the first entry that is equal or less. Make a copy of the number you have, divide it by the table entry, convert the result to integer (1-9) and you now have the first digit and the scale of the number. Convert the integer value back to floating point (or use the original floating point value with fraction truncated), multiply that by the table entry, and subtract the product from the number you have. Now repeat the process for each subsequent table entry (from here on out the ZERO digit may also appear) and that gives you each subsequent digit. Stop when you have enough digits or the number you have becomes zero. Alternatively instead of a table you can start with the highest power of ten possible, and just divide by 10.0 as a substitute for searching the table. Personally I would rather commit the 1.5K bytes to the table and be certain of the accuracy. Only if you are trying to fit a program into an IPL page or the CMS transient area should size be such a tight concern. If you want the macros I mention for DOUBLE INTEGER conversion, send me an Email request asking for "INUDEC MACRO" (unsigned) and/or "INSDEC MACRO" (signed). These are macros that generate functions in several different contexts. You can extract the code from the macro. Or if you wish you can also ask for my "macro function system package" which will include the COPY files needed for the macros to work and some sample macro functions I have written. Email: phil@ux1.cso.uiuc.edu -or- phil-howard@uiuc.edu Bitnet users: tell me if you want me to use CMS SENDFILE over BITNET instead of Email. Don't use my Bitnet address (PHIL@UIUCVMD) unless you absolutely must since I don't regularly read my mail there. If you send me a file there send me Email to the above address and tell me to look for the file. -- --Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society <phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.
phil@UX1.CSO.UIUC.EDU (Phil Howard KA9WGN) (02/21/91)
OEYO8729@TREARN.BITNET (Cem TURGAY) writes: >Hello, Hello Cem in Turkey. >Is there anybody out there ? Yes, at least right now there is. >I can't hear anything from you, hey assembly-ers ! >Last time I asked for HX entry of CMS but no one reply to me. >Where are you ? Did you leave the assembler lists ? I can't say for others but it has been a while since I read this. I am reading it via USENET NEWS, not as a mailing list. Hopefully my postings make it back to the mailing list. >Now, I have a problem with to write double word numbers to screen >in assembly ? Do you have any example or macro about floating to >character conversion ? Would you please help to me. Thanks. There are a number of different approaches to doing this. They vary in how accurate the decimal digits are to the binary floating point number. There are some floating point numbers that can require as many at 56 digits of the fractional part to accurately represent in decimal. The reason for this is because each bit is half the value of the previous one in the fraction. Binary Decimal 1.0000 1.0000 0.1000 0.5000 0.0100 0.2500 0.0010 0.1250 0.0001 0.0625 1.1111 1.9375 If the numbers are WHOLE numbers you can convert them to INTEGER and convert them to decimal quickly and accurately. I have a macro that generates an assembler function to do the conversion of signed or unsigned (different ones) double INTEGERS to decimals. One possible approach to converting FLOATING point numbers to decimal is to construct a table of powers of 10 in floating point. Starting with the number to be converted, search the table from the highest value until you find the first entry that is equal or less. Make a copy of the number you have, divide it by the table entry, convert the result to integer (1-9) and you now have the first digit and the scale of the number. Convert the integer value back to floating point (or use the original floating point value with fraction truncated), multiply that by the table entry, and subtract the product from the number you have. Now repeat the process for each subsequent table entry (from here on out the ZERO digit may also appear) and that gives you each subsequent digit. Stop when you have enough digits or the number you have becomes zero. Alternatively instead of a table you can start with the highest power of ten possible, and just divide by 10.0 as a substitute for searching the table. Personally I would rather commit the 1.5K bytes to the table and be certain of the accuracy. Only if you are trying to fit a program into an IPL page or the CMS transient area should size be such a tight concern. If you want the macros I mention for DOUBLE INTEGER conversion, send me an Email request asking for "INUDEC MACRO" (unsigned) and/or "INSDEC MACRO" (signed). These are macros that generate functions in several different contexts. You can extract the code from the macro. Or if you wish you can also ask for my "macro function system package" which will include the COPY files needed for the macros to work and some sample macro functions I have written. Email: phil@ux1.cso.uiuc.edu -or- phil-howard@uiuc.edu Bitnet users: tell me if you want me to use CMS SENDFILE over BITNET instead of Email. Don't use my Bitnet address (PHIL@UIUCVMD) unless you absolutely must since I don't regularly read my mail there. If you send me a file there send me Email to the above address and tell me to look for the file. -- --Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society <phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.
SOMITCW@VCCSCENT.BITNET (02/21/91)
On Wed, 20 Feb 91, oeyo8729@trearn said: >Now, I have a problem with to write double word numbers to screen >in assembly ? Do you have any example or macro about floating to >character conversion ? Would you please help to me. Thanks. I have no examples, it has been years. To convert to characters, do a STD, UNPK, and TR. Multiple UNPK's may be needed. Last byte of the UNPK will be garbage. The TR should point to 240 bytes before table CL16'0123456789ABCDEF'. OR, If you need to convert to decimal numbers, multiply by 1,000,000,000. Do a STD. Separate the whole number from the sign, fractions, etc. Load the whole number into a general purpose register. CVD, UNPK, and put the decimal point back in.