Cobus.Debeer@p0.f1.n491.z5.fidonet.org (Cobus Debeer) (10/12/90)
I have seen some questions regarding the type of problems experienced by use of the JPI V2 compiler. The problems that I had with r1.04 is too numerous to list but I recently received a free update to r1.06 and it is MUCH better than 1.04. The biggest single problem that I have is when I use types REAL or LONGREAL with a co-processor present. When I enable the generation of debug information, something goes wrong. The code geneted works on the first pass through the code but on subsequent passes ( eg the second time through a loop ) something goes wrong. The machine crashes and I traced the cause to an INT 0DD instruction in the program. The strange part is that the INT instruction is not there on the first pass through the code. Initially I suspected that the destination of a jump is calculated incorrectly and that the code is 'out of phase' causing good code to become garbage. When I examine the memory before executing the code I see good code. I noted down the data at the relevant address and stepped through the code until I observe the INT. I examined the memory again and lo and behold, it was changed. I now suspect that VID has a dangling pointer and that it clobbers my program at some point in time. However, when I compile the code without debug information, it works. (sometimes ) When I turn on the run time error checking then the program again crashes without message and hangs the machine. I am lost ! I have reported this problem to JPI and sent them the disk with the sample code that demonstrates the problem. I am a little disapointed that they released a version of the compiler with this problem still unsolved. In fairness I must add that the new compiler produces very fast code. A second problem is related to the graphics module. The function that detects the presence of Hercules Adaptors does not work correctly with some 'El Cheapo' clones. The reason seems to be that they are not identical to the HGA. Now, if you distribute a program that reports 'Graphics Adaptor not supported' when all other programs run on this hardware then the developer is considred to be a dolt. Also Borland can correctly detect these funny adaptors so it can be done. This was also reported. I have found a fix which has a side effect that the color Hercules cards can't be detected and while implementing this in the new source I notice that it was changed ( quite substancially ) but I don't care that they tried. I want the problem fixed because these adaptors are part of the real world and they can't be wished out of existance and I must deliver code that works on whatever platform the user has ( within reason ). The user blames me because all other software work on their systems. Why am I still using JPI M2 ? I have a lot of code that use their library and I invested a substancial amount in the compiler. Also, the early (1.17) version of the compiler works really well and is ( was ) very fast. The library was not quite extensive enough so I would like to switch to the new version. What is the price of the Stony Brooke Library Source ? Regards - Cobus de Beer -- uucp: uunet!m2xenix!puddle!5!491!1.0!Cobus.Debeer Internet: Cobus.Debeer@p0.f1.n491.z5.fidonet.org
Ian.Macintosh@f15.n491.z5.fidonet.org (Ian Macintosh) (10/17/90)
On <11 Oct 1990 21:02>, Cobus Debeer wrote to All: CD>LONGREAL with a co-processor present. When I enable the CD>generation of debug information, something goes wrong. The code CD>geneted works on the first pass through the code but on CD>subsequent passes ( eg the second time through a loop ) CD>something goes wrong. The machine crashes and I traced the CD>cause to an INT 0DD instruction in the program. The strange CD>part is that the INT instruction is not there on the first pass CD>through the code. Initially I suspected that the destination of CD>a jump is calculated incorrectly and that the code is 'out of CD>phase' causing good code to become garbage. When I examine the CD>memory before executing the code I see good code. I noted down CD>the data at the relevant address and stepped through the code CD>until I observe the INT. I examined the memory again and lo and CD>behold, it was changed. I now suspect that VID has a dangling CD>pointer and that it clobbers my program at some point in time. CD> CD>However, when I compile the code without debug information, it CD>works. (sometimes ) When I turn on the run time error checking CD>then the program again crashes without message and hangs the CD>machine. I am lost ! Debuggers that handle machine language use some technique to stop your program after it has executed an instruction. On the 80XXX family you could use the special int/instruction built into the CPU for this purpose (I forget how it works exactly, and I'm too lazy to go find the data), or you can use another technique that used to be very prominent in CPU's without this capability. What the debugger did, was dissasemble the next instruction and then after determining the exact byte length, replace the next byte(s) with an int or call to the debugger (this was used for breakpoints and single stepping). So possibly the debugger is the cause of the problem? You could verify this by creating a breakpoint in the data area of a test program, and then execute the program which will output the contents of the breakpoint address. If you get the Int 0DD bytes there, you got dat bug. If you find a Bug there, squashing him might prove difficult, so consider another debugger if at all possible (I have never use M2 before, so I haven't the foggiest idea of what the debugging process entails there) Regards, Ian. -- uucp: uunet!m2xenix!puddle!5!491!15!Ian.Macintosh Internet: Ian.Macintosh@f15.n491.z5.fidonet.org