Robert.Barton@p0.f6.n105.z1.fidonet.org (Robert Barton) (06/12/90)
Does Topspeed also allow you to specify in which order parameters are pushed, i.e. last first as opposed to first first? -- uucp: uunet!m2xenix!puddle!6.0!Robert.Barton Internet: Robert.Barton@p0.f6.n105.z1.fidonet.org
Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (06/13/90)
Hello Robert:
The following is an example showing how you can specify what registers are used:
(*# call(reg_param=>(es, si, bx)) *)
PROCEDURE Func (c: CHAR; d: LONGCARD; p: ADDRESS);
c will use bx, d uses the stack, and p uses DS:SI.
You can also specify registers used for return values as well as what registers to save.
The pragmas (compiler options) for calling conventions covers a lot of ground. You can force near or far calls, set for same DS (load or do not load the data segment register (DS) on entry), use the C calling convention, do inline expansion of code, specify the segment name, specify DS on entry, supstitute an interrupt return instruction (IRET) instead of a normal return (RET), pass the size of open array parameterGs on the stack, specify that open array parameters are copied onto the stack as part of
the procedure prolog, and specify that a given procedure can have a variable number of parameters (lets you create your own printf-like procedure).
The above only covers the calling pragmas. TopSpeed Modula-2 also has data pragmas, module pragmas, and so on.
TopSpeed Modula-2 2.00 also features conditional compilation. Very much like C's IFDEF.
Although the documentation for 2.00 is poor (Neils Jensen stated they are getting the docs rewritten), and their are some minor bugs (Chris at JPI Tech Support stated they are currently working on the next release --- will be out shortly) --- 2.00 is a lot better than 1.17.
The addition of CLASSes (objects), inheritance, and methods adds a lot to writing reusable code.
JPI has also beefed up their library modules with 2.00.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgborchert@MATHEMATIK.UNI-ULM.DE (Andreas Borchert) (06/27/90)
Scott Canion writes: > On 18-Jun-90, sources inform us that Ola Garstad @ 2:502/100.0 said: > > PM>> and specify that a > PM>> given procedure can have a variable number of parameters (lets you > PM>> create your own printf-like procedure). > > OG> Oh - No! > OG> > OG> THAT will make a lot of non-portable code! > OG> > OG> Looks like JPI is doing it's best to destroy M-2. > > Isn't the term "Portable Modula-2 Code" an oxymoron? I mean, since Wirth > purposely decided -not- to offer any standardized library routines, I think > that really shot portability right out the door.... I don't agree. You don't need standardized libraries for portability. If you have the sources of a complete library then it is sufficient to port your library. An example: I've ported 30,000 lines Modula-2 within 15 hours without any preparation from our UNIX system to JPI Modula-2. I haven't known JPI Modula-2 before. Most of the time was spent on language problems (forward declarations, bugs of JPI-Modula-2, type conversions etc.). Andreas Borchert -- borchert@mathematik.uni-ulm.de borchert@dulruu51.bitnet
Pat.Terry@p101.f4.n494.z5.fidonet.org (Pat Terry) (06/27/90)
> Ola, at present there is no "standard" for the Modula-2 language other > than a "defacto" standard put forth by N. Wirth in PIM3 & PIM4. Reluctantly agreed. > > JPI TopSpeed Modula-2 does conform the the "defacto" standard in PIM3. Oh yea? I can think of at least one non-extension example where it does not DEFINITION MODULE x; PROCEDURE y; END x. IMPLEMENTATION MODULE x; MODULE INNER EXPORT y (*standard*); (* IMPORT y - JPI *) PROCEDURE y; END y; END INNER; END x. Wit a few minutes more i could find several others. > As to creating a portability issue... the programmer is given > complete control as to use only features found in PIM3 or to use PIM3 plus > the extensions. Not really. He has no hint from the JPI compiler as to when he/she is using an extension. Any compiler that claims any "conformance + extension" nonsense should, IMHO, provide this. Please note that I am not against extensions per se. I just want them to be flagged. -- uucp: uunet!m2xenix!puddle!5!494!4.101!Pat.Terry Internet: Pat.Terry@p101.f4.n494.z5.fidonet.org
Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/03/90)
Hello Pat:
I have been hounding Chris at JPI (on JPAM) to add a compiler option to flag extensions.
Chris continues to come back stating that JPI will add a flag when the ISO Standard comes out.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.org