lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (01/19/91)
In article <1991Jan17.212310.2571@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
: As of patch 44, on AT&T SysVr3.2 (386) perl still does a floating
: exception coredump when you <c>ontinue in the debugger. The Configure
: script claims to have noticed a problem casting weird floats to unsigned.
I don't have one of those gizmos here, so someone else will have to figure this
out, or at least get me a reasonable stack trace.
: On the 3B2/400 compiling eval.c still aborts with:
: compiler error: switch table overflow
:
: Is there any hope for perl on AT&T unix?
I hope in 4.0 to reorganize the op types so the switch statement can be
optionally broken into two switch statements, but I may run out of time.
Eventually I hope to move to something like threaded code and do away with
the switch altogether, but not in 4.000.
Tried gcc?
Larryles@chinet.chi.il.us (Leslie Mikesell) (01/22/91)
In article <11110@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >In article <1991Jan17.212310.2571@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >: As of patch 44, on AT&T SysVr3.2 (386) perl still does a floating >: exception coredump when you <c>ontinue in the debugger. The Configure >: script claims to have noticed a problem casting weird floats to unsigned. >I don't have one of those gizmos here, so someone else will have to figure this >out, or at least get me a reasonable stack trace. OK - slightly delayed by the fact that core dumps don't work when you execute across RFS(???). The problem is that the test program run by Configure aborts with the floating exception itself, so instead of returning the value you are trying to construct, it returns a 136 that is subsequently used as the value for CASTFLAGS. Changing to #define CASTFLAGS 3 in config.h seems to fix things. (This machine doesn't have the 80387 which might make a difference). >: On the 3B2/400 compiling eval.c still aborts with: >: compiler error: switch table overflow >I hope in 4.0 to reorganize the op types so the switch statement can be >optionally broken into two switch statements, but I may run out of time. >Eventually I hope to move to something like threaded code and do away with >the switch altogether, but not in 4.000. >Tried gcc? I don't think anyone has done gcc for the 3b family. I've been told that AT&T can provide a version of the compiler with larger tables, but I haven't had a day to spend on the phone trying to get it yet. PL28 was the last that compiled on the 3b with the stock compiler. Les Mikesell les@chinet.chi.il.us
stripes@eng.umd.edu (Joshua Osborne) (01/22/91)
In article <1991Jan21.212620.1547@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: [...] > I don't think anyone has done gcc for the 3b family. I've been told that > AT&T can provide a version of the compiler with larger tables, but I > haven't had a day to spend on the phone trying to get it yet. PL28 > was the last that compiled on the 3b with the stock compiler. There is, but you have to use an older gcc to compile the newer gcc (the curent gcc won't compile even w/ BAND_AID_COMPILER defined), or get the binarys. I don't rember where they are stored, check out the gnu.* groups for more info... -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)
rdc30med@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) (01/23/91)
In article <1991Jan21.212620.1547@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > >I don't think anyone has done gcc for the 3b family. I've been told that >AT&T can provide a version of the compiler with larger tables, but I >haven't had a day to spend on the phone trying to get it yet. PL28 >was the last that compiled on the 3b with the stock compiler. > Noone has yet done a port of gcc to the 3b2 family although it is being worked on. The hardest part to begin with is the correct machine definition files for the WE32xxx chips. I would like to report that perl-3.044 compiles and passes all tests on my 3B2/600G system with stock SysVr3.2.2 compiler. I haven't tried using the debugger like Les has. -- Mike Dobson, Sys Admin for | Internet: rdc30med@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30med AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb or nrd0mxd@vmnmdsc WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com
jmm@eci386.uucp (John Macdonald) (01/24/91)
In article <1991Jan21.212620.1547@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: |>: As of patch 44, on AT&T SysVr3.2 (386) perl still does a floating |>: exception coredump when you <c>ontinue in the debugger. The Configure |>: script claims to have noticed a problem casting weird floats to unsigned. | | The problem is that the test program run by |Configure aborts with the floating exception itself, so instead of |returning the value you are trying to construct, it returns a 136 |that is subsequently used as the value for CASTFLAGS. Changing to |#define CASTFLAGS 3 in config.h seems to fix things. (This machine |doesn't have the 80387 which might make a difference). That rang a bell - I saw a floating point exception during Configure too - and have the same 136 in CASTFLAGS. This is on an old version of Interactive 386/ix (1.0.5 compiler on 1.0.6 system). I don't recall for sure whether we have a 387 - I think we do though. |>: On the 3B2/400 compiling eval.c still aborts with: |>: compiler error: switch table overflow | |>Tried gcc? | |I don't think anyone has done gcc for the 3b family. There definitely is for the 3b1, and I think there is for the 3b2. (We have a slight variation of this theme of compiler limits and 3b - our 386/ix yacc has a small internal state table, so we end up having to use a 3b1 as a yacc server for the 386. On the other hand, the 386 compiler has a nice feature - it automatically turns off -O when it would cause the compile to fail, so I don't have to diddle the makefile to turn -O off by hand for eval.c. -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386