🚀 go-pugleaf

To: INFO-M2%UCF1VM.bitnet@jade.berkeley.edu
Subject: Re: Logitech M2 Compilers
Newsgroups: comp.lang.modula2
In-Reply-To: <INFO-M2%89041123451842@UCF1VM>
Organization: Image Processing Cntr, Univ of Va.
Cc:

In article <INFO-M2%89041123451842@UCF1VM> you write:
>
>Rumour has it that the compiler division of Logitech folded and no longer
>supports their Modula-2 compiler product line; does anyone have any information
>substantiating this?  Also, their VMS compiler seems not to conform to standard
>calling procedures (when trying to link to C code this was discovered) and many
>system calls requiring ADDRESSes seem not to function correctly.  If anyone
        else
>has had luck with such routines, please reply with E-MAIL.
>

Rob Rothkopf,
Chairman of Computer Resources
College of Natural Sciences & Mathematics
State University of New York at Buffalo
404 Wilkeson Quad, Amherst Campus
Buffalo, New York  14261
(716) 636-2235

I hope that it is not true that Logitech is abandoning their M2 compilers!
If you have heard anything definite about that rumor, I would appreciate
the info.

I have made good use of the Logitech VMS compiler. Version 4.0-1 opsys
interface definition modules appear to work well, though I haven't used all
of them, of course.

If you have a version on the compiler before 4.0, it would pay to get the
later one, since they seem to have made a number of improvements which make
it fit into the VMS environment better. Especially, they made it easy to
call M2 procs from other languages. I have had good success using my M2
modules from VMS C programs (and also vice-versa, but UNFORTUNATELY, my
boss is requiring new code be written in C).

I would be glad to send you examples of C linked code or of any of our M2
support modules you might be interested in. I've accumulated a number of
useful (admittedly non-standard) routines including:
                    "MagTape0", raw magtape handling procs
                    "Terminal", an extented replacement for Logitech's
                    "AnsiTerminal", screen oriented output for ANSI codes
                    "EditKeyboard", ANSI keycode reading
                    "TextIO", a TextFile parameterized InOut
                    "In1", guared input of numbers and strings
                    "DynStr0", dynamic memory string handling procs
                     etc.

One problem with the supplied opsys $FOREIGN DEFINITION MODULES I have run
into, however, is that for parameters marked as string descriptor passing
(%STDESCR) will always pass a string, even if empty. VMS, however, sometimes
uses a string descriptor address of 0 to mean no string, which has different
implications from an empty string.

Thus, for such a case you may need to write your own foreign definition module
with an %IMMED ADDRESS parameter. (I have appended an example at the end here.)

Generally, though, the fact that the M2 compiler will construct the string
descriptor for you makes it easier to call these opsys routines with it than
with, say, the DEC VMS C compiler.


Logitech CommonInputOutputProcedures.DEF has:

PROCEDURE LIB$GET_FOREIGN
( VAR %STDESCR getstr : ARRAY OF CHAR ;
      %STDESCR prompt : ARRAY OF CHAR ;
  VAR          outlen : CARDINAL ;
  VAR          forcep : BOOLEAN ) : CARDINAL ;



(*##########################################*)
 %FOREIGN DEFINITION MODULE SilentGETFOREIGN;     (* v1.0-112088 *)
(*##########################################*)
(*
        Necessary since Logitechs module CommonInputOutputProcedures
        Version 4.0-0 of FEBRUARY 1987 does not provide for null prompt,
        which is needed bypass prompting if no command line exists.

*)

FROM SYSTEM IMPORT ADDRESS;

EXPORT QUALIFIED LIB$GET_FOREIGN;

PROCEDURE LIB$GET_FOREIGN
( VAR %STDESCR getstr : ARRAY OF CHAR ;
      %IMMED prompt   : ADDRESS;           (* should be set to zero *)
  VAR          outlen : CARDINAL ;
  VAR          forcep : BOOLEAN ) : CARDINAL ;

END SilentGETFOREIGN.