Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tektronix!nosun!qiclab!m2xenix!puddle!p0.f1.n491.z5.fidonet.org!Cobus.Debeer
From: Cobus.Debeer@p0.f1.n491.z5.fidonet.org (Cobus Debeer)
Newsgroups: comp.lang.modula2
Subject: JPI r1.06b
Message-ID: <294.27158668@puddle.fidonet.org>
Date: 12 Oct 90 04:02:34 GMT
Sender: ufgate@puddle.fidonet.org (newsout1.26)
Organization: FidoNet node 5:491/1.0 - Golden City Opus, Johannesburg RSA
Lines: 62

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