ILU With SRC Modula-3 v 3.5

Ok, I've been trying to get ILU to work with M3, and have had mixed results. The ILU code expected version 2.08 of the Modula 3 compiler which was the same language, but had some significant differences in the libraries.

Here is a list of the problem interfaces and what I basically did to get around them.

The Runtime

The runtime is the big hack with this work. Most of the other stuff is small potatoes compared to this.

All of this work has been done on Solaris 2.4 using SRC version 3.5.1. Your mileage may vary. I've replicated most of this on SunOS 4.1.3 using version 3.5.1, so I have some reason to believe these wild claims are legit.

All of this was done with ILU version 1.8 and assumes you are familiar with ILU and have convenient access to the ILU 1.8 source tree.

Below is a tar file that you can grab to get the runtime system. It will unpack into a directory called ilu-m3. It will have three subdirectories, SOLsun, SPARC, and src. If you are either a SPARC or SOLsun shop, you can probably just use my prebuilt versions.

If you want to make changes to the runtime, there is one crucial piece of information you must know. You must build KernelShim.o by hand and pass the correct compile options to your C compiler to get it to build a position independent object file suitable for use with a shared library. Mod3 now builds shared libraries and the KernelShim.o binary gets glommed into libilu-m3.so and (thus) must be position independent. On Solaris I think the option you need is -G and on SunOS I think the option is -pic. I found that the easiest thing to do was just to try to get ILU built using its default makefiles and let it die in the M3 runtime. It will build the KernelShim.o file, but not for a shared library. Then I just cut-n-pasted a new option into the compile line.

Post Scriptum: Quentin Stafford-Fraser suggested the following to get your m3makefile to compile the file correctly for you:

* I compile the KernelShim.o by putting

   m3_option("-X1@-I/usr/local/ilu/include@")   (or appropriate path)
   c_source("KernelShim")

  in the m3makefile.  As long as your system is set up to produce shared 
libraries by default, this should work fine.

Other than this tricky file, building/changing the runtime should require very little work. Just edit the appropriate files and change the m3makefile to point to where your libilu.{a,so} is located and everything should be fine.

Click Here To Get The 3.5.1 Runtime

Using The Runtime

I did not change the stubber and it appears to work correctly; you can just use the m3-stubber as is. So the only real trick to using the runtime is getting it linked in correctly. You have to use an override (since you probably don't want to m3ship this library). You can do this with a couple of lines like this in your m3makefile:

override("ilu-m3","/users/projects/src/sun4-5/ilu/src/runtime/m3/ilu-m3") import("ilu-m3")

I have tried a couple of the foogen examples and they appear to work just fine. I am not sure which of these I got to work and which I didn't but here are some tar files that may help you in your efforts to see if you got things working. I might add that I don't know how to build multiple programs in one m3makefile, so each program is in its own directory.

Post Scriptum: Quentin Stafford-Fraser suggested a workaround for the two programs in one directory with one m3makefile:

* You mention that you don't know how to build two programs in one m3makefile.
   This is very tricky, but I often use something like m3build -DSERVER, along
   with

     if defined("SERVER")

  in the m3makefile - you can then use the same m3makefile for both, but you 
have to run m3build twice. Not sure if you knew about that.
A word of warning about these examples: Bill Janssen informed me that there were some bugs in the code of these examples. For example, in one case I had to add a line or two just to get them to work right. Again, your mileage may vary.

ILU Stub Generation and m3makefiles

Quentin Stafford-Fraser has written a little quake template that makes life easier when using ILU with M3 3.5.1. Here is the relevant information:
If you make the changes below
to the m3makefile and create the file ilu.tmpl as listed, then your programs
can have in *their* m3makefiles lines like:

        import("ilu")
        iluInterface("Foo","/home/fraser/interfaces")

this causes Foo.isl in the directory /home/fraser/interfaces to be passed to
m3-stubber if needed (ie. if it is more recent than Foo.i3).  All the stubs
will be generated in the m3 build directory, and compiled as required. 

-------- Add to the ilu-m3 m3makefile -------------------------

template("ilu")

-------- Create as file "ilu.tmpl" ----------------------------

% A simple m3build template for ilu-m3

% IluInterface(X) means
% the file X.isl is an ILU interface file which will be given to m3-stubber
% The resulting files X.i3, X_x.i3, X_y.m3, X_c.m3, X_s.m3 will be compiled.
% The interface can be in any directory - the generated stubs will always be
% put in the build directory.

STUBBER=m3-stubber
STUBBERFLAGS="-dir ."

readonly proc do_gen(islfile) is
  exec(STUBBER, STUBBERFLAGS ,islfile)
end

readonly proc isl_iface(y, dir) is
  local islfile = dir & SL & y & ".isl"
  local ifile = y & ".i3"
  if defined("_all")
    if stale(ifile, islfile)
        do_gen(islfile)
    end
  end
end

readonly proc iluInterface(x, dir) is
  isl_iface(x, dir)
  derived_interface(x, HIDDEN)
  derived_interface(x & "_x", HIDDEN)
  derived_implementation(x & "_y")
  derived_implementation(x & "_s")
  derived_implementation(x & "_c")
end

-------- And then m3build and m3ship ilu-m3 ----------------------------

The Problem

Well, everything was going just fine until I tried to use ILU to solve a little problem I was having. I wanted to build a little network audio daemon which could play files remotely (mainly so I could use mosaic on one of the big servers and have the audio work right!). I didn't get very far on this project before things started not working. I get an ASSERTION from the M3 runtime inside the thread scheduler whenever I try to use my own code with the new M3 runtime. I traced the problem to a check to make sure the top of the thread stack was still valid, and it isn't. So I think it is safe to assume that somehow I am getting into a recursion-fest and overflowing the stack.

If you would grab this code and give it a try and/or try to figure out what is wrong, I'd certainly appreciate it. I'd love to hear that I did something wrong in my code and the runtime is ok. Note: In that tar file you may find some stuff that I was using to try to get at the bottom of this thread problem, so try to ignore it... Thanks.

I guess that's about it... send me mail if you have any questions/comments.


Ian Smith (iansmith@cc.gatech.edu)

Last Modified 3 Apr 95 by Ian Smith (iansmith@cc.gatech.edu)