James.Jackson@f200.n208.z1.fidonet.org (James Jackson) (06/13/90)
So are you saying, I could purchase top speed modula (2.2 is it?) and make it take some full C source, compile it and make a full stand alone *.EXE out of it.. without a line of Modula? So I could still program in C, and then take modula into my programs a little at a time when I see necessary to do so? I'd be interested to know more about Modula2's capabilities of handling, especially specifically HOW it handles something like C, or Asm source. Thanks James -- uucp: uunet!m2xenix!puddle!208!200!James.Jackson Internet: James.Jackson@f200.n208.z1.fidonet.org
TRL3@psuvm.psu.edu (Tim Larson) (06/17/90)
In article <5716.2677A5D1@puddle.fidonet.org>, James.Jackson@f200.n208.z1.fidonet.org (James Jackson) says: > >So are you saying, I could purchase top speed modula (2.2 is it?) and >make it take some full C source, compile it and make a full stand alone >*.EXE out of it.. without a line of Modula? So I could still program in >C, and then take modula into my programs a little at a time when I see >necessary to do so? > Nope. JPI has nicely separated the compiler, etc. from the environment and code generator. Thus you can work on a program where module 1 is C, module B is ASM, and module III is Modula-2, tell the environment to make it and the make correctly calls the appropriate compiler. Of course, you have to *have* the appropriate compiler. Is there more to it? You bet there is! You have to be aware of what you are asking the whole system to do. First, you must settle on a calling convention which you inform the system of using pragmas. Also, the linker has to know all about the naming conventions (more pragmas). Register usage (more pragmas). The docs seem to guide you through this well enough, but you must do it right. Furthermore, you have to be aware of things like what libraries you are using; suppose you pull in stdio in C and IO in M2. You just got two IO packages for the price of two! You can call the C i/o routines within M2, so don't use IO, etc. You have to be even more aware of these issues when you use third party modules so you don't swell the program to some enormous size. The upshot? JPI has done a nice job here of simplifying what was already possible (with effort) but you must be aware of all the ramifications. Perhaps, with some experience from 2.0, JPI will smooth out the process even more, but I suspect that it will always be necessary to understand the underlying problems. BTW: I've only just started looking into this, and it looks great from the standpoint of providing libraries to JPI, but what other uses could this have? Seems like portability sort of goes out the window, especially since JPI doesn't seem interested in 680x0 architectures or Unix, etc. (or did I miss a press leak somewhere?) Does anybody know what 2.0 looks like in terms of the draft standard? (I haven't had time to explore the draft myself.) Cheers! -Tim Larson trl3@spuvm.bitnet "I'm not bad...I'm just drawn that way." -Jessica Rabbit