Extacy 
Author Message
 Extacy

Has anyone used the Extacy compiler under OS/2?

David Eidelman
McGill University



Wed, 07 Feb 1996 05:58:55 GMT  
 Extacy
: Has anyone used the Extacy compiler under OS/2?

An additional question. How does Extacy or other Oberon's
without GC's handle memory manangement ? Do they use
a Pascal/Modula DISPOSE or they use a library routine
such as Storage.Dispose( ptr ) for the purpose.

Whitney  



Wed, 07 Feb 1996 11:08:16 GMT  
 Extacy
: Has anyone used the Extacy compiler under OS/2?

Okay, I know this dumb but I will answer my own question.  I downloaded
the demo extacy version for DOS and successfully compiled the demos for
32 bit OS/2 using the Borland OS/2 compiler.  It worked without any problems
although there were several minor warnings.  I was even able to set up a
make file to handle rebuilds.  It is a bit annoying to use this version under
OS/2 as a DOS session has to be created every time XC.EXE is called.  

It was interesting to note that the slow part of the compile was in the
C compiler not the Modula-2 compiler.

David Eidelman
McGill University



Wed, 07 Feb 1996 23:57:30 GMT  
 Extacy

Quote:


>: Has anyone used the Extacy compiler under OS/2?

>An additional question. How does Extacy or other Oberon's
>without GC's handle memory manangement ? Do they use
>a Pascal/Modula DISPOSE or they use a library routine
>such as Storage.Dispose( ptr ) for the purpose.

>Whitney

I really hope GC will be in next version 1.40.x :-).

You should use SYSTEM.NEW and SYSTEM.DISPOSE, according to latest  (June
1993) Oberon-2 language standard.

--
 ----------------------------------------------------------


 Real Time Associates             CompuServe: 71333,2346
 Canning House, 59 Canning Road   Tel: (+44) (0)81 656 7333
 Croydon, Surrey, CRO 6QF, UK     Fax: (+44) (0)81 655 0401
 ----------------------------------------------------------



Thu, 08 Feb 1996 03:22:00 GMT  
 Extacy

Quote:


>: Has anyone used the Extacy compiler under OS/2?

>Okay, I know this dumb but I will answer my own question.  I downloaded
>the demo extacy version for DOS and successfully compiled the demos for
>32 bit OS/2 using the Borland OS/2 compiler.  It worked without any problems

Funny enough but never heard about :-) So I pleased Extacy proved to  be
portable again :-)

Quote:
>although there were several minor warnings.  I was even able to set up a
>make file to handle rebuilds.  It is a bit annoying to use this version under

Makefile generator will help, but it is not included into demo.

Quote:
>OS/2 as a DOS session has to be created every time XC.EXE is called.

We have a port under OS/2 you know,  but  we  made  demo  for  DOS  only
because it has a lot of crazy limitations itself, so we patched compiler
in numerious places :-)

Quote:
>It was interesting to note that the slow part of the compile was in the
>C compiler not the Modula-2 compiler.

I know. C compilers usually surprisingly slow (at least in compare  with
Extacy which compiles about 1500 lines/sec = 90 000 lines/min on my 486,
which is not on the top of a modern technology at all, and does not have
even a cache :-)

Quote:
>David Eidelman
>McGill University

--
 ----------------------------------------------------------


 Real Time Associates             CompuServe: 71333,2346
 Canning House, 59 Canning Road   Tel: (+44) (0)81 656 7333
 Croydon, Surrey, CRO 6QF, UK     Fax: (+44) (0)81 655 0401
 ----------------------------------------------------------



Thu, 08 Feb 1996 03:30:02 GMT  
 Extacy
: >OS/2 as a DOS session has to be created every time XC.EXE is called.

: We have a port under OS/2 you know,  but  we  made  demo  for  DOS  only
: because it has a lot of crazy limitations itself, so we patched compiler
: in numerious places :-)

What is the price of the OS/2 version?  Are there any educational
discounts?

By the way, the version of x2c.c that ships with the DOS compiler checks
to make sure that arrays are less than 64K.  To make the compiler work
correctly as a 32-bit system it is necessary to comment out this kludge.

David Eidelman
McGill University



Fri, 09 Feb 1996 05:49:03 GMT  
 Extacy

   >An additional question. How does Extacy or other Oberon's
   >without GC's handle memory manangement ? Do they use
   >a Pascal/Modula DISPOSE or they use a library routine
   >such as Storage.Dispose( ptr ) for the purpose.

   I really hope GC will be in next version 1.40.x :-).

   You should use SYSTEM.NEW and SYSTEM.DISPOSE, according to latest  (June
   1993) Oberon-2 language standard.

I can't find any mention of DISPOSE in the description of the SYSTEM
module in the Oberon2.Report.Text that comes with the SPARC System 3
implementation (dated July 1993?).  Also, the beginning of the
description of the SYSTEM module states that the contents of the
SYSTEM module are "particular to a given computer and/or
implementation" so that fact that the Ceres implementation described
therein might have a DISPOSE doesn't really have any bearing on other
implementations.



Fri, 09 Feb 1996 01:41:56 GMT  
 Extacy

Quote:


>   >An additional question. How does Extacy or other Oberon's
>   >without GC's handle memory manangement ? Do they use

>   You should use SYSTEM.NEW and SYSTEM.DISPOSE, according to latest  (June
>   1993) Oberon-2 language standard.

>I can't find any mention of DISPOSE in the description of the SYSTEM
>module in the Oberon2.Report.Text that comes with the SPARC System 3
>implementation (dated July 1993?).

At the Croydon meeting, the compiler developers decided to allow non-GC
compilers to implement a SYSTEM.DISPOSE which would be the equivalent of a
C 'free' or C++ 'delete' or Modula-2/Pascal 'DISPOSE'.  On systems which
support GC, SYSTEM.DISPOSE, if supported, is supposed to be a procedure
that will mark the block as 'collectable'.

It is not required that all compilers implement this SYSTEM procedure, but
many probably will.

Yes, the very notion of a compiler that does not support GC, and using
SYSTEM.DISPOSE to free memory makes the module non-portable.

Taylor "1 PETE" Hutt
Trash accumulates in stagnant water. -- Japanese proverb



Fri, 09 Feb 1996 10:54:45 GMT  
 Extacy

Quote:

>Yes, the very notion of a compiler that does not support GC, and using
>SYSTEM.DISPOSE to free memory makes the module non-portable.

Whoops, I meant to say:

Yes, the very notion of an Oberon system that does nto support GC....

Taylor "Revisionist" Hutt
ProverbMan or OberonMan... Which hat to wear today?



Fri, 09 Feb 1996 19:15:48 GMT  
 Extacy
Is there a way to control/create the decorations of
C functions generated by Extacy Oberon-2. Borlands C/C++
compiler on OS/2 supports _export directive that
indicates the function is to be exported from the DLL.

I want the following sort of translation.

MODULE mylib;

PROCEDURE foo*;
BEGIN END foo;

END mylib.

void _export _syscall mylib_foo()
{

Quote:
}

-------------------------------------

Just for fun here is the same example of a C function
exported from a DLL using a standard calling convention.
But this time it is for a C++ compiler that uses the latest
C++ extension - namespaces. Isn't this powerful ;-)

namespace mylib {
        extern "C" {
                void _export _syscall foo()
                {
                }
        }

Quote:
}

Whitney


Sat, 10 Feb 1996 12:03:37 GMT  
 Extacy
Hello,

Quote:


>: >OS/2 as a DOS session has to be created every time XC.EXE is called.

>: We have a port under OS/2 you know,  but  we  made  demo  for  DOS  only
>: because it has a lot of crazy limitations itself, so we patched compiler
>: in numerious places :-)

>What is the price of the OS/2 version?  Are there any educational
>discounts?

You could find an answer in enclosed documentation. Price  for  OS/2  is
USD $230 or GBP #150, and there is no educational discount available for
Personal Computer platforms (which includes OS/2), unlike Personal  Unix
and Workstation platforms options (off 50% for educationalists).  Please
notice (and complete information is in enclosed documentation  as  well)
that if you purchase more than 2 user licence  you  get  a  discount  as
well.

Quote:
>By the way, the version of x2c.c that ships with the DOS compiler checks
>to make sure that arrays are less than 64K.  To make the compiler work
>correctly as a 32-bit system it is necessary to comment out this kludge.

I perfectly know about because it was my right  (and  left)  hand  which
pressed Ctrl-Y in editor to remove ALL machine-independant stuff and  AI
from X2C.c and X2C.h. What you get is "_msdos" and "X2C_index16" version
:-). Indeed, these files determine "host" configuration on-the-fly,  but
you do not see it in demo version.

And I can quarantee it will work on any Intel 80x86 CPU computer.

So, as long as it was made intentionally and you had been told about  in
enclosed documentation, I believe it is perfectly OK.

I think it is fair play: you get a fully-functional demo FOR MSDOS  ONLY
(!) for free and decide for yourself what the animal is it  and  do  you
want it at all, but I have a right to introduce  artificial  limitations
into compiler, patch X2C.* to make it highly MSDOS-dependant (it was not
very easy work, and I am personally proud about the number of  invisible
holes and Intel specific things it contain), and do not include complete
documentation, libraries, and other utilities combined with Extacy.

With best regards,

Andrew Cadach

--
 ----------------------------------------------------------


 Real Time Associates             CompuServe: 71333,2346
 Canning House, 59 Canning Road   Tel: (+44) (0)81 656 7333
 Croydon, Surrey, CRO 6QF, UK     Fax: (+44) (0)81 655 0401
 ----------------------------------------------------------



Fri, 09 Feb 1996 22:43:37 GMT  
 Extacy

Quote:

>Is there a way to control/create the decorations of
>C functions generated by Extacy Oberon-2. Borlands C/C++
>compiler on OS/2 supports _export directive that
>indicates the function is to be exported from the DLL.

>I want the following sort of translation.

>MODULE mylib;

>PROCEDURE foo*;
>BEGIN END foo;

>END mylib.

>void _export _syscall mylib_foo()
>{
>}

In current release, the answer is "no".

However we are thinking to supply  compiler  equation  (placed  in  your
x2c.cfg or project file) like

#CEXPORT=_export _syscall

or, for Windows programming :-) :-(

#CEXPORT=_far _pascal /* exported function */
%#CEXPORT=WINAPI /* exported function */

and compiler will simply put this text at any  prototype/declaration  of
global  function  right  before  function  name,  if  [possibly  inline]
compiler option EXPORTED is ON.

Thus, in your case, text should looks like so:
#CEXPORT=_export _syscall /* exported function */
:O2ISOPRAGMA

MODULE mylib; <*+ EXPORTED *>

PROCEDURE foo*;
BEGIN END foo;

END mylib.

The only problem is a procedure variables, types, and run-time library.

Right now (and generally speaking, in M2 and O2) there is only one class
of procedure types. In  C,  there  could  be  several  of  them  -  with
different calling convention to apply.

And I see no way to work it around.

Presumably, we can add this line to ANY (not only global)  prototype  or
declaration of [pointer to] function.

I do not know right now which  decision  will  be  better:  affect  only
global functions (and have possible  problems  with  incompatible  types
trying to assing such a procedure to a pointer),  or  affect  everything
(no problems with incompatible types, but what compiler  will  think  if
I'll declare local function as "_export _stdcall"?  will  it  cause  any
collisions? how about run-time library? probably it would be better this
case  to  use  some  predefined  name  as   X2C_PROCLASS   and   #define
X2C_PROCLASS to nothing or whatever you like in X2C.h  -  and  therefore
RTS will be consistant with other stuff).

Any help and  suggestions  will  be  gratly  appreciated,  and  we  will
implement as soon as correct solution is found.

What about me, I think that '#define X2C_PROCLASS'  is  much  better.  I
think it should cause no problems declaring local functions as '_pascal'
for Windows, or as '_export' for OS/2.

However, I cannot check it for ALL C  compilers  for  OS/2  and  Windows
simply because I do not have all of them.  If  you'd  compile  following
test with your compiler and then send  me  a  short  message  containing
description of C compiler, its version, etc., and what  it  think  about
:-), I will be able to make a right decision.

------------------ cut here ------------------
#if defined (OS2) || defined (__OS2__)
#define XXX _export
#else
#include "windows.h"
#define XXX WINDAPI
#endif
typedef void XXX type1 (void);
static type1 *var1;
typedef void (XXX * type2) (void);
static type2 var2;
static void (XXX * var3) (void);
static void XXX inst1 (void) {}
static int XXX inst2 (type1 *par1, type2 par2, void (XXX *par3)(void))
{
  return (par1 == par2 &&
          par1 == par3 &&
          par1 == var1 &&
          par1 == var2 &&
          par1 == var3);

Quote:
}

int XXX test (void)
{
  var1 = inst1;
  var2 = inst1;
  var3 = inst1;
  return inst2 (inst1, inst2, inst3);
Quote:
}

------------------ cut here ------------------

Thanks in advance.

- Show quoted text -

Quote:
>Just for fun here is the same example of a C function
>exported from a DLL using a standard calling convention.
>But this time it is for a C++ compiler that uses the latest
>C++ extension - namespaces. Isn't this powerful ;-)

>namespace mylib {
>        extern "C" {
>                void _export _syscall foo()
>                {
>                }
>        }
>}

>Whitney

Yupp :-) :-(.

--
 ----------------------------------------------------------


 Real Time Associates             CompuServe: 71333,2346
 Canning House, 59 Canning Road   Tel: (+44) (0)81 656 7333
 Croydon, Surrey, CRO 6QF, UK     Fax: (+44) (0)81 655 0401
 ----------------------------------------------------------



Sat, 10 Feb 1996 17:41:30 GMT  
 Extacy
: Hello,
: >By the way, the version of x2c.c that ships with the DOS compiler checks
: >to make sure that arrays are less than 64K.  To make the compiler work
: >correctly as a 32-bit system it is necessary to comment out this kludge.

I wasn't complaining.  Just letting other potential users know.  For a
freeware demo, the package you have released is very impressive.

On the other hand, I believe I have found a bug.

If I make the Oberon call

        NEW( x, 512, 480 );

Then LEN(x,0) seems to come out as 480 and LEN(x,1) as 512.

As far as I understand Oberon syntax this is incorrect.

(I still like EXTACY and will probably buy the OS/2 version. I am just
trying to be helpful).

David Eidelman
McGill University



Sun, 11 Feb 1996 08:14:54 GMT  
 Extacy

: >Is there a way to control/create the decorations of
: >C functions generated by Extacy Oberon-2. Borlands C/C++
: >compiler on OS/2 supports _export directive that
: >indicates the function is to be exported from the DLL.
: >

: The only problem is a procedure variables, types, and run-time library.

: Right now (and generally speaking, in M2 and O2) there is only one class
: of procedure types. In  C,  there  could  be  several  of  them  -  with
: different calling convention to apply.

Taking a hint from the Oberon/Ceres design. I see two possible
calling conventions for three function prototype forms.
The calling conventions are for calls local to a module or
for across module boundries. Procedure variables fall in the
camp of calls across module boundries. The Oberon/Ceres hint
could be used to assign non-exported procedures to procedure
variables.

In Oberon :

exportable
VAR p : PROCEDURE( VAR msg : Msg);

PROCEDURE LocalProcedure;
void LOCALPROC MyLib_LocalHandler  or
void MyLib_LocalHandler

PROCEDURE * LocalHandler( VAR msg : Msg );
void MARKEDLOCALPROC MyLib_LocalHandler( ...

PROCEDURE ExportedProcedure*( VAR msg : Msg );
void EXPORTPROC MyLib_ExportedProcedure( ...

The user supplies the #defines for LOCALPROC, MARKEDLOCALPROC, EXPORTPROC
in the standard include file X2C.h ( ? )
For Borland C on OS/2 I would use :
#define LOCALPROC
#define MARKEDLOCALPROC _syscall
#define EXPORTPROC _export _syscall

For IBM's ICC I would use :
#define LOCALPROC
#define MARKEDLOCALPROC _SysCall
#define EXPORTPROC _SysCall

ICC requires .DEF files for the DLL's. Wouldn't it be nice
if those could be generated automagically as well :-)

Whitney



Sun, 11 Feb 1996 11:08:30 GMT  
 Extacy

Quote:


>: >Is there a way to control/create the decorations of
>: >C functions generated by Extacy Oberon-2. Borlands C/C++
>: >compiler on OS/2 supports _export directive that
>: >indicates the function is to be exported from the DLL.
>: >

>: The only problem is a procedure variables, types, and run-time library.

>: Right now (and generally speaking, in M2 and O2) there is only one class
>: of procedure types. In  C,  there  could  be  several  of  them  -  with
>: different calling convention to apply.

>Taking a hint from the Oberon/Ceres design. I see two possible
>calling conventions for three function prototype forms.
>The calling conventions are for calls local to a module or
>for across module boundries. Procedure variables fall in the
>camp of calls across module boundries. The Oberon/Ceres hint
>could be used to assign non-exported procedures to procedure
>variables.

For this type of work, the Oberon [] notation would probably be better.

For example:

PROCEDURE [1] WindowsCallback;
PROCEDURE [4] WindowsExported;

(I forget if I have the bracket in the right place or not)
The compiler vendor would provide the meaning for the integer in the
brackets.  The translator would interpret the integer, and provide the
proper coding of the output C function.

This is how MacOberon programs can interface with the underlying system,
according to one ETH attendee at the London meeting, so it would be
feasible to use this for a C translator's intricate interactions with
Windows.

Taylor "Windows are for kids" Hutt
Like pain?  Try scratching your cornea!  Now THAT is pain!



Sun, 11 Feb 1996 20:43:43 GMT  
 
 [ 29 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Q: place for demo (Extacy 2.0)

2. Extacy whereabouts

3. Oberon libraries for Extacy.EXE

4. IS Extacy Oberon-2 Oberon-2?

5. Extacy RTS bug fix

6. Extacy portable Oberon-2 and Modula-2 compiler demo is available on ftp

7. Extacy Oberon-2/Modula-2 available on ftp

8. Extacy Oberon-2/Modula-2 available on ftp

9. Q: place for demo (Extacy 2.0)

10. Extacy whereabouts

11. Extacy Demo compiler problem

12. Extacy RTS bug fix

 

 
Powered by phpBB® Forum Software