🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.modula2
Article #1277

re: FLAME ON; JPI Pragma inline

#1277
From: Larry M. Jordan
Date: Wed, 24 Oct 1990 00:00
37 lines
2636 bytes
re: FLAME ON
------------
  Frank, you say the system "typically runs out of memory on the second
allocation."  "Typical" for whom?  Obviously, not typical for me, even
though my applications tend to be heap intensive.  I called JPI tech.
support for the details.  Unless they're lying to me, the circumstances
for the problem seemed pretty obscure--Only those applications which
where "close to using all available memory, and those that happened to
deallocate the last byte of whole segments."  I'm not denying your
experience, but your account does seem to distort through overstatement.  
JPI says the problem was fixed in r1.06.  Have you verified this?  

  As to your other remarks: One of the "Heavy duty" (your term, not 
mine) applications I have been working on the past year-and-a-half is a compiler.  It's not very large as compilers go--41 modules and roughly 8500 
SLOC.  The language is an object-oriented extension to Modula-2 I designed and
implemented for my Master's thesis in CS.  I translate the source form into
Modula-2 and use, in this instance, JPI to compile/debug the generated code.
Among other things, the compiler/translator builds a concrete representation 
of the source for use by subsequent passes.  This is a graph built from the 
heap.  No heap problems, then or now.

Pragma Inline
-------------
 
  I will also continue to post what I consider to be interesting and
and unique capabilities (and any and all problems I encounter).

  I successfully exercised the INLINE capability of the JPI product in
a grand way this weekend.  I knew the internal representation for my compiler
would be changing over time so I hid it behind a wall of interfacing 
procedures.  Most of these are small, and if I were doing this in C, I would 
have made them macros. In a matter of minutes I made these 40 or so procedures 
INLINE via the appropriate JPI pragmas, exposed the opaque declaration, moved 
the procedure bodies into the definition and recompiled.  The final executable 
is slightly larger (155K vs. 145k) and it still works!  I successfully 
recompiled all my test cases with the new executable.  I've been waiting for
a performance tuning capability like this for Modula-2 for years.
Technical Details
Message-ID: <89437@aerospace.AERO.ORG>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!elroy.jpl.nasa.gov!aero!jordan

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!elroy.jpl.nasa.gov!aero!jordan
From: jordan@aerospace.aero.org (Larry M. Jordan)
Newsgroups: comp.lang.modula2
Subject: re: FLAME ON; JPI Pragma inline
Message-ID: <89437@aerospace.AERO.ORG>
Date: 24 Oct 90 00:00:51 GMT
Organization: The Aerospace Corporation, El Segundo, CA
Lines: 37