[Fwd: Re: [SLE] Real Numbers representation in Tcl language]

newer
[SLE] internet problem with suse 10

older
Re: [SLE] Novell Network Client...

John E. Perry

12 Apr 2006 12 Apr '06

19:30

Sorry Greg, I forgot the SLE reply-to quirk.

Attachments:

SLERealNumbersrepresentationinTcllanguage.eml (message/rfc822 — 2.8 KB)

Show replies by date

Greg Wallace

12 Apr 12 Apr

22:32

On Wednesday, April 12, 2006 @ 2:30 PM, John E. Perry wrote:

...

Sorry Greg, I forgot the SLE reply-to quirk.

No problem. I didn't realize the program used software to elevate the values for ordinates and mantissas beyond the machine's hardware limits. Very interesting. I'm obviously way behind the times on how math functionality is implemented in the modern PC era! Good info. Greg Wallace

Carlos E. R.

23:19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-04-12 at 17:32 -0500, Greg Wallace wrote:

...

No problem. I didn't realize the program used software to elevate the values for ordinates and mantissas beyond the machine's hardware limits. Very interesting. I'm obviously way behind the times on how math functionality is implemented in the modern PC era! Good info.

Remember that the intel x86 processors did not come with floating point math: that was done by an add on procesor, and it was expensive. I'm not sure when they started to have the f. math unit was included in the main procesor, but somewhere in the pentium series, I guess. Therefore, in the PC world compilers had to include libraries for simple things as multipliying 2.3 * 5.4. Even gcc (or the kernel?) still contains an (optional) emulation library. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEPYsctTMYHG2NR9URAuOCAKCANldif4UxpfIAPRkl0lvGPRQPVgCdHfoa Dx1SdmjQNdGEvMin/dxkUpU= =blwC -----END PGP SIGNATURE-----

Patrick Shanahan

23:45

* Carlos E. R. [04-12-06 19:20]:

...

Remember that the intel x86 processors did not come with floating point math: that was done by an add on procesor, and it was expensive. I'm not sure when they started to have the f. math unit was included in the main procesor, but somewhere in the pentium series, I guess.

I believe the 80286 possessed floating point but perhaps it first appeared in the 80186 which was almost unknown. The 8086 and 8088 did not. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2

Carlos E. R.

13 Apr 13 Apr

00:31

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-04-12 at 19:45 -0400, Patrick Shanahan wrote:

...

I believe the 80286 possessed floating point but perhaps it first appeared in the 80186 which was almost unknown. The 8086 and 8088 did not.

The f.p. math was in the 8087 coprocesor. I have an 386 machine for which I got a 387 coprocesor some years later, if I remember right: I'd have to open it up to check, and I'm sleepy right now ;-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEPZvmtTMYHG2NR9URAmL6AJ9mJgxE3mHpS6tX+PNVmXwKF0/QbACgivkb Gyw2am/HXpYMIXZ6eSWXKs8= =H1pj -----END PGP SIGNATURE-----

Jim Cunning

00:59

On Wednesday 12 April 2006 16:45, Patrick Shanahan wrote:

...

I believe the 80286 possessed floating point but perhaps it first appeared in the 80186 which was almost unknown. The 8086 and 8088 did not. AFAIK the 80286 and 80386 (mentioned earlier by Carlos E. R.) only had floating point coprocessor (80[23]87) chips, like the 8087 for the 8086 and 8088 CPUs. The 80486DX processor had on-chip floating point, as do all Pentiums, I believe.

The 80186 and 80188 were 16-bit bus and 8-bit bus versions of the 8086 and 8088 that included a few more instructions, plus on-chip DMA and interrupt controllers, counter/timers, and logic to generate chip-select signals that reduced the number of chips needed to build embedded systems. There were a few consumer PC-type products using the 80186/80188, but many embedded computer products. There was also an 80187 FP coprocessor for the 80188/80186. Jim

Carlos E. R.

12:17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-04-12 at 17:59 -0700, Jim Cunning wrote:

...

The 80186 and 80188 were 16-bit bus and 8-bit bus versions of the 8086 and 8088 that included a few more instructions, plus on-chip DMA and interrupt

The 8086 was also 16 bit. Almost everybody used the 8088, but I was fortunate that my first PC had an 8086, and was noticeably faster. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEPkFHtTMYHG2NR9URAkwGAJ9PZb3XUQBQzZKM8KWd6iorrjgnAgCfdoMp /6lcLlEcOqE8iL0UTvfVl4I= =FgHP -----END PGP SIGNATURE-----

John E. Perry

02:33

Carlos E. R. wrote:

...

Remember that the intel x86 processors did not come with floating point math: that was done by an add on procesor, and it was expensive. I'm not sure when they started to have the f. math unit was included in the main procesor, but somewhere in the pentium series, I guess.

The first microprocessor to have on-chip floating-point hardware was the 80486DX. All before that, from all vendors, used coprocessors, if they had any floating-point hardware at all.

...

Therefore, in the PC world compilers had to include libraries for simple things as multipliying 2.3 * 5.4. Even gcc (or the kernel?) still contains an (optional) emulation library.

Even mainframes didn't have floating-point hardware; until Intel shocked the world with the 8087, everyone said there was no possibility in the foreseeable future of doing floating-point in hardware :-). Once Intel showed the way, of course, everyone went into a crash program to catch up. John Perry

Greg Wallace

05:26

On Wednesday, April 12, 2006 @ 9:34 PM, John Perry wrote:

...

Carlos E. R. wrote:

...

...
Remember that the intel x86 processors did not come with floating point math: that was done by an add on procesor, and it was expensive. I'm not sure when they started to have the f. math unit was included in the main procesor, but somewhere in the pentium series, I guess.

The first microprocessor to have on-chip floating-point hardware was the 80486DX. All before that, from all vendors, used coprocessors, if they had any floating-point hardware at all.

...

...
Therefore, in the PC world compilers had to include libraries for simple things as multipliying 2.3 * 5.4. Even gcc (or the kernel?) still contains

...

...
an (optional) emulation library.

Even mainframes didn't have floating-point hardware; until Intel shocked the world with the 8087, everyone said there was no possibility in the foreseeable future of doing floating-point in hardware :-). Once Intel showed the way, of course, everyone went into a crash program to catch up.

...

John Perry

When you say "mainframes didn't have floating-point hardware ...", how far back in the mainframe world are we speaking? For example, did the IBM 360 have floating point hardware, or did that not come along until the 370 or 30xx machines? Greg Wallace

John E. Perry

13:03

Greg Wallace wrote:

...

When you say "mainframes didn't have floating-point hardware ...", how far back in the mainframe world are we speaking? For example, did the IBM 360 have floating point hardware, or did that not come along until the 370 or 30xx machines?

Mainframes in the '60's, '70's, and early '80's were built with small-scale and medium-scale integrated circuits -- AND, OR, registers, maybe an occasional special chip of the same level of complexity. Intel at the time was leading the world in integrated circuit complexity. The 4004, a 4-bit microprocessor chip, came out in 1971, and was by far the most complex chip ever built at the time. The 8087, the first math coprocessor, came out in 1980, and was again the most complex chip ever built. The 80486DX, the first processor with on-chip floating-point, came out in 1989. Again, the most complex chip ever built. None of the mainframe companies were anywhere near the microprocessor companies' levels of integration, as far as I know, until the late '80's and '90's. That's why they built machines that could do little or no more, but cost millions of dollars. There were comments when the IBM PC came out in 1981 that they probably used the 8087 as the basis for the PC because the 68K machine they'd already built cost a tenth the price of their low-end mainframe, and was substantially faster :-). I don't know what was in the IBM managers' minds, but I do know they had a 68K machine that was much faster than the PC: I had one at work. At home, in 1984, I bought a $400 Radio Shack TRS-80 Color Computer, which ran Microsoft Basic (the same software as on the PC) more than twice as fast as the $5000 IBM PC my colleague bought :-). It used an 8-bit Motorola 6809 processor. John Perry

Jerry Feldman

14:30

On Thursday 13 April 2006 1:26 am, Greg Wallace wrote:

...

When you say "mainframes didn't have floating-point hardware ...", how far back in the mainframe world are we speaking? For example, did the IBM 360 have floating point hardware, or did that not come along until the 370 or 30xx machines? I'm pretty sure that the IBM 360s had floating point hardware, but that may have been optional. I am 100% sure that the instruction set included floating point instructions.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Jerry Feldman

14:36

...

On Wednesday, April 12, 2006 @ 2:30 PM, John E. Perry wrote:

...
Sorry Greg, I forgot the SLE reply-to quirk.

No problem. I didn't realize the program used software to elevate the values for ordinates and mantissas beyond the machine's hardware limits. Very interesting. I'm obviously way behind the times on how math functionality is implemented in the modern PC era! Good info. This has always been true. Today, 128 bit long doubles are generally done in software. Additionally, some IEEE functionality is implemented in software. For instance, most floating point numbers are stored in normalized format, but there are numbers greater than 0.0 but less than the minimum normalized number that generally require software. These are called denormals, and

On Wednesday 12 April 2006 6:32 pm, Greg Wallace wrote: those are one of the reasons that most compilers generate "fast floating point" by default because strict IEEE compliance can be very slow. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Ken Jennings

14 Apr 14 Apr

01:05

On Thursday 13 April 2006 10:36, Jerry Feldman wrote:

...

On Wednesday 12 April 2006 6:32 pm, Greg Wallace wrote:

...
On Wednesday, April 12, 2006 @ 2:30 PM, John E. Perry wrote:

...
Sorry Greg, I forgot the SLE reply-to quirk.

No problem. I didn't realize the program used software to elevate the values for ordinates and mantissas beyond the machine's hardware limits. Very interesting. I'm obviously way behind the times on how math functionality is implemented in the modern PC era! Good info.

...

This has always been true. Today, 128 bit long doubles are generally done in software. Additionally, some IEEE functionality is implemented in software. For instance, most floating point numbers are stored in normalized format, but there are numbers greater than 0.0 but less than the minimum normalized number that generally require software. These are called denormals, and those are one of the reasons that most compilers generate "fast floating point" by default because strict IEEE compliance can be very slow.

What type will designate some kind of floating point value as 128-bit? Here sizeof long double == 12 bytes (96 bits) on Amd Athlon XP 2500+

Jerry Feldman

12:23

On Thursday 13 April 2006 9:05 pm, Ken Jennings wrote:

...

On Thursday 13 April 2006 10:36, Jerry Feldman wrote:

...
On Wednesday 12 April 2006 6:32 pm, Greg Wallace wrote:

...
On Wednesday, April 12, 2006 @ 2:30 PM, John E. Perry wrote:

...
Sorry Greg, I forgot the SLE reply-to quirk.

No problem. I didn't realize the program used software to elevate the values for ordinates and mantissas beyond the machine's hardware limits. Very interesting. I'm obviously way behind the times on how math functionality is implemented in the modern PC era! Good info.

This has always been true. Today, 128 bit long doubles are generally done in software. Additionally, some IEEE functionality is implemented in software. For instance, most floating point numbers are stored in normalized format, but there are numbers greater than 0.0 but less than the minimum normalized number that generally require software. These are called denormals, and those are one of the reasons that most compilers generate "fast floating point" by default because strict IEEE compliance can be very slow.

What type will designate some kind of floating point value as 128-bit?

Here sizeof long double == 12 bytes (96 bits) on Amd Athlon XP 2500+ Implementation defined. On my 32-bit workstation is it 96 bits, on 2 different Linux 64-bit systems it is 128 bits (IA64 and X86_64)

IA64 RHEL 4.0 [gaf@cedar C]$ ./ldsize Sizeof long double is 16 SuSE 10 32-bit system gaf@sauron:~/src/C> gcc ldsize.c -o ldsize gaf@sauron:~/src/C> ./ldsize Sizeof long double is 12 td190> ./ldsize Sizeof long double is 16 td190> uname -a Linux td190 2.6.5-7.252-smp #1 SMP Tue Feb 14 11:11:04 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Maura Edeweiss Monville

17:02

Did you implement the utility named "ldsize" yourself ? I cannot find it in SuSE DVDs. Thanks, Maura On Fri, 14 Apr 2006, Jerry Feldman wrote:

...

On Thursday 13 April 2006 9:05 pm, Ken Jennings wrote:

...
On Thursday 13 April 2006 10:36, Jerry Feldman wrote:

...
On Wednesday 12 April 2006 6:32 pm, Greg Wallace wrote:

...
On Wednesday, April 12, 2006 @ 2:30 PM, John E. Perry wrote:

...
Sorry Greg, I forgot the SLE reply-to quirk.

No problem. I didn't realize the program used software to elevate the values for ordinates and mantissas beyond the machine's hardware limits. Very interesting. I'm obviously way behind the times on how math functionality is implemented in the modern PC era! Good info.

This has always been true. Today, 128 bit long doubles are generally done in software. Additionally, some IEEE functionality is implemented in software. For instance, most floating point numbers are stored in normalized format, but there are numbers greater than 0.0 but less than the minimum normalized number that generally require software. These are called denormals, and those are one of the reasons that most compilers generate "fast floating point" by default because strict IEEE compliance can be very slow.

What type will designate some kind of floating point value as 128-bit?

Here sizeof long double == 12 bytes (96 bits) on Amd Athlon XP 2500+ Implementation defined. On my 32-bit workstation is it 96 bits, on 2 different Linux 64-bit systems it is 128 bits (IA64 and X86_64)

IA64 RHEL 4.0 [gaf@cedar C]$ ./ldsize Sizeof long double is 16

SuSE 10 32-bit system gaf@sauron:~/src/C> gcc ldsize.c -o ldsize gaf@sauron:~/src/C> ./ldsize Sizeof long double is 12

td190> ./ldsize Sizeof long double is 16 td190> uname -a Linux td190 2.6.5-7.252-smp #1 SMP Tue Feb 14 11:11:04 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

Maura Edeweiss Monville

21 Apr 21 Apr

23:00

I'd like to point to your attention that the Tcl/Tk libraries are still the stumbling block at installing a Monte Carlo code which uses both the CERN library and (unfortunately) a Tcl/Tk based GUI. I would like to emphasize that the SAME installation (same scripts, same Makefiles, same Tcl/Tk procedure) is actually working in a Japan research center on a Linux x86_64 cluster running Red Hat and provided with an earlier version of the gcc compiler (verion 3.3.4). On my laptop provided with the same x86_64 processor, a later gcc version (3.3.5) the SAME installation fails when I run the overall GNUmakefile that should create the Monte Carlo executable. I'm pasting the errors I get showing that the linker, for some reason that only a SuSE guru can probably explain, does not link the RIGHT Tcl/Tk library file stating it is incompatible ! Why ? Please, notice everything was recompiled on my laptop with the option m32 placd in every Makefile ... just as in the japanese installation. mauede@linux:/home/mokhov/restricted/mars15> make g77 -m32 -static -L/home/mauede/cernlib.32-2005-ifh.de/2005/lib -L/home/mokhov/restricted/mars15/linux/lib -L/home/mokhov/restricted/mcnp4c/linux/lib -L/home/mokhov/restricted/mars15/linux/lib -L/home/mokhov/restricted/mars15/linux/lib -o rmars-bnab-fems-linux marsmain.o m1505.o -lm15gui_linux -lm15linux -lm15fems_linux -lm15trneu_linux -lm15treem_linux -lm15eve_linux -lm15cem03_linux -lm15ext_linux -lm15blb_linux -lm15mpino_linux -lm15linux -lpacklib -ltk8.3 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lnsl -lpthread /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lm15gui_linux collect2: ld returned 1 exit status make: *** [rmars-bnab-fems-linux] Error 1 Someone keeps asking me why I do not replace the Tcl/Tk procedure with the Tcl/Tk that comes with SuSE or with a more recent one. The reason is that the provided Tcl/Tk procedure creates and places some Tcl/Tk libraries (".a" files for instance the one that is not linked) and some Tcl/Tk includes (.h files). If someone kindly tells me HOW to reproduce the same Tcl/Tk structure by using another Tcl/Tk distribution I'll be glad to give it a try. I do not know how to do that from what comes with SuSE DVD or is downloaded from any website. Unluckily I cannot attach any file that would better explain the situation as it would be cut off by the SuSE mail server. By the way, even using the command linux32 before running the Tcl/Tk procedure generates the same results ! Nothing changes. Thank you in advance to everyone who can explain to me what is wrong with SuSE... I might switch to Red Hat if thsi makes my life less miserable ... Maura On Wed, 12 Apr 2006, John E. Perry wrote:

...

Sorry Greg, I forgot the SLE reply-to quirk.

Roger Oberholtzer

22 Apr 22 Apr

06:21

On Fri, 2006-04-21 at 18:00 -0500, Maura Edeweiss Monville wrote:

...

I'd like to point to your attention that the Tcl/Tk libraries are still the stumbling block at installing a Monte Carlo code which uses both the CERN library and (unfortunately) a Tcl/Tk based GUI. I would like to emphasize that the SAME installation (same scripts, same Makefiles, same Tcl/Tk procedure) is actually working in a Japan research center on a Linux x86_64 cluster running Red Hat and provided with an earlier version of the gcc compiler (verion 3.3.4).

On my laptop provided with the same x86_64 processor, a later gcc version (3.3.5) the SAME installation fails when I run the overall GNUmakefile that should create the Monte Carlo executable. I'm pasting the errors I get showing that the linker, for some reason that only a SuSE guru can probably explain, does not link the RIGHT Tcl/Tk library file stating it is incompatible ! Why ? Please, notice everything was recompiled on my laptop with the option m32 placd in every Makefile ... just as in the japanese installation.

mauede@linux:/home/mokhov/restricted/mars15> make g77 -m32 -static -L/home/mauede/cernlib.32-2005-ifh.de/2005/lib -L/home/mokhov/restricted/mars15/linux/lib -L/home/mokhov/restricted/mcnp4c/linux/lib -L/home/mokhov/restricted/mars15/linux/lib -L/home/mokhov/restricted/mars15/linux/lib -o rmars-bnab-fems-linux marsmain.o m1505.o -lm15gui_linux -lm15linux -lm15fems_linux -lm15trneu_linux -lm15treem_linux -lm15eve_linux -lm15cem03_linux -lm15ext_linux -lm15blb_linux -lm15mpino_linux -lm15linux -lpacklib -ltk8.3 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lnsl -lpthread /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lm15gui_linux collect2: ld returned 1 exit status make: *** [rmars-bnab-fems-linux] Error 1

Someone keeps asking me why I do not replace the Tcl/Tk procedure with the Tcl/Tk that comes with SuSE or with a more recent one. The reason is that the provided Tcl/Tk procedure creates and places some Tcl/Tk libraries (".a" files for instance the one that is not linked) and some Tcl/Tk includes (.h files). If someone kindly tells me HOW to reproduce the same Tcl/Tk structure by using another Tcl/Tk distribution I'll be glad to give it a try. I do not know how to do that from what comes with SuSE DVD or is downloaded from any website.

The problem has, it seems to me, nothing to do with Tcl. It seems to be that it is because you are trying to link with files compiled somewhere else. I guess that is what -lm15gui_linux is, right? Do you have the source for all this? If not, you may be SOL. If so, then you should recompile everything on the target platform.

...

Unluckily I cannot attach any file that would better explain the situation as it would be cut off by the SuSE mail server. By the way, even using the command linux32 before running the Tcl/Tk procedure generates the same results ! Nothing changes.

Thank you in advance to everyone who can explain to me what is wrong with SuSE... I might switch to Red Hat if thsi makes my life less miserable ...

Nothing is wrong with SUSE. The problem is with the libm15gui_linux you have picked up somewhere. Could you explain exactly where that file came from? How it was compiled? Again, do you have the sources for making it? -- Roger

6585

Age (days ago)

6595

Last active (days ago)

List overview

Download

16 comments

9 participants

participants (9)

Carlos E. R.
Greg Wallace
Jerry Feldman
Jim Cunning
John E. Perry
Ken Jennings
Maura Edeweiss Monville
Patrick Shanahan
Roger Oberholtzer