ooc-compiler

Re: [ooc-compiler] Language Shootout - a couple of problems

[Stewart G. <sgr...@ii...>]

Hi Isaac,

> Current OO2C implementations are shown at:
>    http://shootout.alioth.debian.org/lang/oberon2/
>
> 1) Brent reports that for n=40000 Hash.ob2 gives 0 instead of 9999
>    oo2c -M --no-rtc Hash.ob2
> However it works fine on my machine. Suggestions?
>
> 2) moments.oberon2 works fine for input size 1, but for input size 50
>    Segmentation fault

I couldn't try these, as they depend on some modules that are not 
listed. Are these files available via CVS or something?

You shouldn't get a segmentation fault, unless it is due to an 
unchecked run-time error. Try running the program with run-time 
checking enabled. If it still segfaults, carefully check your use of 
unsafe functions from module SYSTEM. If you use gdb, you should be able 
to localise the error using the backtrace function.

Looking at moments.oberon, I think the use of SYSTEM.MOVE is buggy. To 
copy an array of <N> REALs, you need to use <N*SIZE(REAL)> as the 
length parameter. You are probably getting a garbled array by not 
copying the whole thing. Also, I would avoid the use of ASH, since it 
is probably not faster than just multiplying by 2. Actually, it would 
be nice to have  a type-safe way of quickly copying arrays (eg. like 
Java's System.arraycopy)

>
> 3) Suggestions on improving the performance of the file processing
> programs (or any other programs) would be appreciated: wc.oberon2,
> spellcheck.oberon2, sumcol.oberon2.

It depends what these benchmarks are trying to measure. If they are 
trying to measure the speed of the underlying I/O facilities, they are 
probably fine. However, if you look at the examples that run fast, 
these all do buffering inside the application itself. For example, the 
gcc implementation does not use getchar(), but instead uses read() to 
read a chunk of data into a buffer, and then works on that array. You 
can do the same using the IO modules, and you should get similar 
performance.

For example, try something like this:

MODULE Wc2;
IMPORT IO, IO:StdChannels, Out;

VAR
    insideWord: BOOLEAN;
    nc, nl, nw: LONGINT;
    in : IO.ByteChannel;
    buffer : ARRAY 4096 OF CHAR;
    i, count : LONGINT;

BEGIN
    nc := 0; nl := 0; nw := 0;
    insideWord := FALSE;
    in := StdChannels.stdin;
    REPEAT
      count := in.Read(buffer, 0, LEN(buffer) * SIZE(CHAR));
      FOR i := 0 TO count-1 DO
         INC(nc);
         CASE buffer[i] OF
            | 0AX :
               INC(nl);
               insideWord := FALSE;
            | 9X, 20X :
               insideWord := FALSE;
         ELSE
            IF ~insideWord THEN
               insideWord := TRUE;
               INC(nw);
            END;
         END;
      END;
    UNTIL count <= 0;

    Out.Int(nl,1); Out.Char(20X); Out.Int(nw,0); Out.Char(20X);
    Out.Int(nc,0); Out.Ln;
END Wc2.

At least on my system, this version is about 10 times faster, even with 
run-time checks enabled. You should find that the same technique makes 
the other IO-based benchmarks run much faster too.

Cheers,
   Stewart

[ooc-compiler] Language Shootout - a couple of problems

[Isaac G. <ig...@ya...>]

Current OO2C implementations are shown at: 
   http://shootout.alioth.debian.org/lang/oberon2/

1) Brent reports that for n=40000 Hash.ob2 gives 0 instead of 9999
   oo2c -M --no-rtc Hash.ob2
However it works fine on my machine. Suggestions?

2) moments.oberon2 works fine for input size 1, but for input size 50 
   Segmentation fault

3) Suggestions on improving the performance of the file processing
programs (or any other programs) would be appreciated: wc.oberon2,
spellcheck.oberon2, sumcol.oberon2.

best wishes, Isaac


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: [ooc-compiler] DLL creation with oo2c?

[Frank H. <fh...@ph...>]

Thanks for the detailed explications.
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Brasil

Re: [ooc-compiler] DLL creation with oo2c?

[Stewart G. <sgr...@ii...>]

On Wednesday, July 21, 2004, at 08:55  AM, Frank Hrebabetzky wrote:

>> The information to which shared library a module belongs to is
>> available in some places, although it is not passed on into the
>> generated C code until now.  The current code base writes information
>> on library membership into the modules' symbol file.  Adding it to the
>> header files as well should be easy, since the .oh and .Sym carry
>> pretty much the same information, only in different formats.
>> Don't know if this is sufficient, though, since it only covers the
>> identity of the used code.  It looks to me like the identity of the
>> using code plays into this dllimport/export issue as well.
>> -- mva
>
> I don't fully understand this, but my reasoning is the following:
>
> - A DLL is a piece of executable code.
> - Once code is compiled, the source language doesn't matter any more.
> - So if DLLs can be generated from C source, this should be possible
>   for Oberon too.

Correct. But the source language does matter up to a point:

- The procedures need to use the same calling convention. Normally,  
this will be pascal (stdcall) or C (cdecl). Both are supported by OOC  
at present, as is fastcall and vtable method dispatch. There are  
additional conventions used by C++ compilers which are not supported  
(eg. thiscall).

- Any data structures need to use compatible layouts. Using OOC, you  
can control alignment in records so this is not likely to be a problem.  
OOC also supports some interoperability between C and Oberon-2 strings  
(ie. via CSTRING).

- To link correctly, the languages need to use compatible names for  
procedures and variables. OOC decorates function names by appending the  
module name. For example, procedure "P" in module "M" is called "P__M"  
in the object file. I believe that you can override this naming by  
supplying your own name. Of course, you are then responsible for  
ensuring that you don't generate name clashes between module. A similar  
issue exists with C++ since it decorates procedure names with type  
information (ie. to support name overloading).

- Another option to handle language-independent linking is via COM.  
This is also possible using OOC, since you can access and implement COM  
objects via VTABLE records.

> So why would you need to know which shared library a module belongs to?

The linker needs to know which symbols are to be imported and exported  
by the DLL or EXE. There are two ways of specifying this: via a  
hand-built ".DEF" file, or by tagging declarations in the source code  
(ie: __declspec(dllexport) to export a function, __declspec(dllimport)  
to import a function).

If you are prepared to build your own ".DEF" file, then there is no  
problem. You could probably even do this with existing object files  
generated by the mingw32 compiler and the appropriate link commands.  
This might work if you have just a few functions to declare.

To use the tagging approach, the C compiler needs to know explicitly  
which functions are imported and exported between DLLs. One way to do  
it is like this:

IF module "A" is part of a library, THEN every exported object  
(variable, procedure, type descriptor) is declared DECL_A in the  
oo2c-generated header files.

At compile-time (ie. by gcc), the meaning of DECL_A changes.

IF compiling the implementation of module "A" THEN
   DECL_A is "__declspec(dllexport)"
ELSE (* compiling a module "B" that imports "A" *)
   IF "A" and "B" are modules in the same library THEN
     DECL_A is ""
   ELSE
     DECL_A is "__declspec(dllimport)"
   END
END

This can probably be done with a little trickery using the  
pre-processor, but to make it work OOC needs tag the generated ".oh"  
files so that the C compiler knows whether an imported module is in the  
same or a different DLL. However, this is a general solution which  
should allow you to mix and match modules across DLL boundaries.

One final issue is initialisation. Normally, OOC calls the module  
initialisation statements from the main() function. For a DLL, this  
should logically be done from the DLL entry point. I'm not sure how  
this is currently handled. I believe that OOC currently only links  
libraries at load-time, not at run-time. In this case, the  
initialisation might still all be done from main(). If your DLL is to  
be loaded at run-time, or into a foreign language environment, it would  
need to do the initialisation in DllMain().

Here are some relevant references:
   
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ 
vccore98/html/_core_dll_tasks.asp
   
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ 
vccore98/html/_core_export_from_a_dll.asp
   
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ 
dllproc/base/dynamic_link_library_entry_point_function.asp

Cheers,
   Stewart

Re: [ooc-compiler] DLL creation with oo2c?

[Frank H. <fh...@ph...>]

Michael van Acken wrote:
> Stewart Greenhill <sgr...@ii...> writes:
> 
> 
>>Hi Frank,
>>
>>
>>>2 reasons why it would be nice to generate DLLs with oo2c:
>>>
>>>- Using oberon in larger projects even when others use other languages
>>>- Using oberon when the main program has to be in another language,
>>>e.g. when it is created by a tool.
>>
>>Agreed.
>>
>>
>>>Anything existing (working) or planned? My expert level: just
>>>managed to  compile a dll-hello-world version with mingw following
>>>some examples on the web :-) .
>>
>>My understanding is that there is now some level of support for DLLs
>>in libtool.
>>   http://www.belgeler.org/autobook/autobook-DLLs-with-Libtool.html
>>
>>For the Windows DLL architecture, functions that are exported or
>>imported from DLLs have to be specially declared using:
>>   __declspec(dllimport)
>>   __declspec(dllexport)
>>Normally, some preprocessor tricks are used so that a header file
>>defining a module can be used for both import and export. The
>>declaration is changed according to whether the compiled file is in
>>the same or different DLL. It would need a little thought to determine
>>what sort of model would work within oo2c. For Windows, we could add
>>these tags into the compiler-generated declarations, but this would
>>require the compiler to track which modules are grouped together in
>>which libraries. I think it already does this, but I can't say for
>>sure.
> 
> 
> The information to which shared library a module belongs to is
> available in some places, although it is not passed on into the
> generated C code until now.  The current code base writes information
> on library membership into the modules' symbol file.  Adding it to the
> header files as well should be easy, since the .oh and .Sym carry
> pretty much the same information, only in different formats.
> 
> Don't know if this is sufficient, though, since it only covers the
> identity of the used code.  It looks to me like the identity of the
> using code plays into this dllimport/export issue as well.
> 
> -- mva
> 

I don't fully understand this, but my reasoning is the following:

- A DLL is a piece of executable code.
- Once code is compiled, the source language doesn't matter any more.
- So if DLLs can be generated from C source, this should be possible
   for Oberon too.

So why would you need to know which shared library a module belongs to?
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Brasil

Re: [ooc-compiler] Language Shootout and GCC 3.3.4

[Michael v. A. <Mic...@de...>]

Stewart Greenhill <sgr...@ii...> writes:

> [...]
> For the Windows DLL architecture, functions that are exported or
> imported from DLLs have to be specially declared using:
>    __declspec(dllimport)
>    __declspec(dllexport)
> Normally, some preprocessor tricks are used so that a header file
> defining a module can be used for both import and export. The
> declaration is changed according to whether the compiled file is in
> the same or different DLL. It would need a little thought to determine
> what sort of model would work within oo2c. For Windows, we could add
> these tags into the compiler-generated declarations, but this would
> require the compiler to track which modules are grouped together in
> which libraries. I think it already does this, but I can't say for
> sure.

The information to which shared library a module belongs is available
in some places, although it is not passed on into the generated C code
until now.  The current code base writes information on library
membership into the modules' symbol files.  Adding it to the header
files as well should be easy, since the .oh and .Sym carry pretty much
the same information, only in different formats.

Don't know if this is sufficient, though, since it only covers the
identity of the used code.  It looks to me like the identity of the
using code plays into this dllimport/export issue as well.

-- mva

Re: [ooc-compiler] DLL creation with oo2c?

[Stewart G. <sgr...@ii...>]

Hi Frank,

> 2 reasons why it would be nice to generate DLLs with oo2c:
>
> - Using oberon in larger projects even when others use other languages
> - Using oberon when the main program has to be in another language, 
> e.g. when it is created by a tool.

Agreed.

> Anything existing (working) or planned? My expert level: just managed 
> to  compile a dll-hello-world version with mingw following some 
> examples on the web :-) .

My understanding is that there is now some level of support for DLLs in 
libtool.
   http://www.belgeler.org/autobook/autobook-DLLs-with-Libtool.html

For the Windows DLL architecture, functions that are exported or 
imported from DLLs have to be specially declared using:
   __declspec(dllimport)
   __declspec(dllexport)
Normally, some preprocessor tricks are used so that a header file 
defining a module can be used for both import and export. The 
declaration is changed according to whether the compiled file is in the 
same or different DLL. It would need a little thought to determine what 
sort of model would work within oo2c. For Windows, we could add these 
tags into the compiler-generated declarations, but this would require 
the compiler to track which modules are grouped together in which 
libraries. I think it already does this, but I can't say for sure.

Cheers,
   Stewart

Re: [ooc-compiler] Language Shootout and GCC 3.3.4

[Stewart G. <sgr...@ii...>]

Hi Isaac,

> There are now a number of naive Oberon-2 implementations on "The Great
> Computer Language Shootout"
>
>    http://shootout.alioth.debian.org/lang/oberon2/
>
> It's using GCC 2.1.3 - are there plans to move to GCC 3.3.4?

I think you'll find that "2.1.3" is the OOC version, not the GCC 
version. oo2c should work fine with any recent version of gcc. 
Obviously, any improvements in gcc's optimisation will also benefit 
oo2c.

> Note: the Shootout is in the process of being updated, the remaining
> tests waiting for an implementor are: Echo Client/Server, Regular
> Expression Matching, Exceptions, Producer/Consumer Threads.
>
> New and improved implementations are welcome ;-)

Did you run the shootout benchmarks with or without run-time tests? 
Oberon-2 is a type-safe language, so there is extensive run-time 
testing in the generated code. If you want to compare performance 
against a language like "C" that is not type-safe, it is probably fair 
to disable all run-time tests. This is true particularly if your code 
includes pointers or arrays.

Note that the oo2c source base includes some simple benchmark tests, in 
which we compare the performance of oo2c-generated code to the 
"optimal" C equivalent. At least in these tests we find that the 
performance of the oo2c code is similar to that of optimised C. 
Occasionally, oo2c will spot an optimisation that gcc cannot find and 
we in fact get better performance from the oo2c-optimised code C code. 
For example, in the tests listed below the FFT benchmark exceeds the 
performance of the equivalent C code on all platforms that we tested.

Cheers,
   Stewart

------8<------

Summary of results for:

   Benchmark --all --normalise

All tests are based on oo2c-2.0.6.

--------

gcc-3.2.2, -march=pentium2 -O2, Mobile Pentium II, 400MHz (mva)

   Test             tests/sec % optimal
   -------------------------- -------
   ZeroArray1         16664.2  100.0%
   ZeroArray2         16661.0   99.9%
   ZeroArray4         16659.9  100.0%
   CopyArray1         11948.2   98.1%
   CopyArray2         11457.3  104.3%
   CopyArray4         10005.5   94.4%
   CopyArrayMove      13090.2  100.0%
   AddArray1           8788.5   97.0%
   AddArray2           9148.0   90.4%
   AddArray4          10929.0  100.6%
   ZeroArray1C        16671.6
   ZeroArray2C        16670.5
   ZeroArray4C        16662.0
   ZeroArrayBlockC    19696.7
   CopyArray1C        12182.5
   CopyArray2C        10983.1
   CopyArray4C        10603.7
   CopyArrayBlockC    13083.6
   AddArray1C          9058.8
   AddArray2C         10123.7
   AddArray4C         10864.7
   QSORT                369.9   99.3%
   QSORTC               372.6
   BSORT                157.6  100.0%
   BSORTC               157.6
   FFT                 4850.2  120.3%
   FFTC                4031.0
   FFT2                3661.4   87.5%
   FFT2C               4185.2
   -------------------------- -------

gcc-3.2.2, -march=athlon-xp -O2, Athlon XP 1800, 1.5GHz (mva)

   Test             tests/sec % optimal
   -------------------------- -------
   ZeroArray1         76099.6  100.0%
   ZeroArray2        101429.3  100.0%
   ZeroArray4        151342.4   99.7%
   CopyArray1         47038.2   77.5%
   CopyArray2         64995.7   99.5%
   CopyArray4         69222.1   99.9%
   CopyArrayMove      67671.9   99.8%
   AddArray1          34155.6   99.5%
   AddArray2          40611.0  102.8%
   AddArray4          40311.2  103.0%
   ZeroArray1C        76132.7
   ZeroArray2C       101439.1
   ZeroArray4C       151758.6
   ZeroArrayBlockC   150538.5
   CopyArray1C        60667.4
   CopyArray2C        65299.3
   CopyArray4C        69281.5
   CopyArrayBlockC    67807.6
   AddArray1C         34330.0
   AddArray2C         39521.2
   AddArray4C         39137.7
   QSORT               1168.4   89.9%
   QSORTC              1299.7
   BSORT                758.9  100.0%
   BSORTC               758.9
   FFT                22834.8  142.7%
   FFTC               16003.9
   FFT2               16659.9   90.2%
   FFT2C              18472.6
   -------------------------- -------

gcc-3.1, -O2, PPC G3, 700MHz (sg)

   Test             tests/sec % optimal
   -------------------------- -------
   ZeroArray1         23005.2   81.8%
   ZeroArray2         29637.5   94.6%
   ZeroArray4         37743.0  106.8%
   CopyArray1         15963.9   87.7%
   CopyArray2         18818.7   99.9%
   CopyArray4         19490.3  103.6%
   CopyArrayMove      24621.4   99.8%
   AddArray1           9139.0  114.9%
   AddArray2          10338.5  100.0%
   AddArray4          10965.6  102.0%
   ZeroArray1C        28136.1
   ZeroArray2C        31313.9
   ZeroArray4C        35324.6
   ZeroArrayBlockC    45881.5
   CopyArray1C        18200.7
   CopyArray2C        18829.5
   CopyArray4C        18818.7
   CopyArrayBlockC    24658.5
   AddArray1C          7955.8
   AddArray2C         10340.2
   AddArray4C         10750.7
   QSORT                268.5   60.7%
   QSORTC               442.7
   BSORT                153.4   99.9%
   BSORTC               153.5
   FFT                 6702.4  102.9%
   FFTC                6516.5
   FFT2                5580.4   98.5%
   FFT2C               5667.2
   -------------------------- -------

[ooc-compiler] Language Shootout and GCC 3.3.4

[Isaac G. <ig...@ya...>]

There are now a number of naive Oberon-2 implementations on "The Great
Computer Language Shootout" 

   http://shootout.alioth.debian.org/lang/oberon2/

It's using GCC 2.1.3 - are there plans to move to GCC 3.3.4?

Note: the Shootout is in the process of being updated, the remaining
tests waiting for an implementor are: Echo Client/Server, Regular
Expression Matching, Exceptions, Producer/Consumer Threads.

New and improved implementations are welcome ;-)


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

[ooc-compiler] DLL creation with oo2c?

[Frank H. <fh...@ph...>]

2 reasons why it would be nice to generate DLLs with oo2c:

- Using oberon in larger projects even when others use other languages
- Using oberon when the main program has to be in another language, e.g. 
when it is created by a tool.

Anything existing (working) or planned? My expert level: just managed to 
  compile a dll-hello-world version with mingw following some examples 
on the web :-) .
-- 
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Brasil

Re: [ooc-compiler] Application compile runtime error

[Michael v. A. <Mic...@de...>]

Frank Hrebabetzky <fh...@ph...> writes:

> When trying to compile my application ("oo2c testmpp.Mod"), the response is
> 
> ## Runtime error in module OOC:SSA:WriteC at pos 13856
> ## Dereference of NIL
> 
> I am using oo2c_32-2.1.3 under WindowsXP / MingW / MSYS. My program (I
> attached it just in case) has grown pretty large, so just a hint about
> the kind of statement that is bothering, where to look for what, would
> help.

The assigment with SYSTEM.VAL fails.  The following workaround should
preserve your intended semantics without crashing the compiler.

--- testmpp.Mod.orig    Wed Jul  7 10:13:50 2004
+++ testmpp.Mod Wed Jul  7 10:24:29 2004
@@ -118,7 +118,8 @@
     END
   ELSIF str="MOVE" THEN
     cmd:= MOVE;
-    cs:= SYSTEM.VAL(CharSeq, par1);  par1:= ORD(cs[0]);  par2:= ORD(cs[1]);
+    SYSTEM.MOVE(SYSTEM.ADR(par1), SYSTEM.ADR(cs), SIZE(INTEGER));
+    par1:= ORD(cs[0]);  par2:= ORD(cs[1]);
   ELSIF str="MOVREF" THEN cmd:= MOVREF
   ELSIF str="WAIT" THEN
     IF par1<0 THEN cmd:= ERRCMD

I will need to investigate further why this application of VAL does
not work.  If necessary, I will turn this particular scenario into a
compile time error.

-- mva

[ooc-compiler] Application compile runtime error

[Frank H. <fh...@ph...>]

When trying to compile my application ("oo2c testmpp.Mod"), the response is

## Runtime error in module OOC:SSA:WriteC at pos 13856
## Dereference of NIL

I am using oo2c_32-2.1.3 under WindowsXP / MingW / MSYS. My program (I 
attached it just in case) has grown pretty large, so just a hint about 
the kind of statement that is bothering, where to look for what, would help.

--
Frank Hrebabetzky
Brasil

[ooc-compiler] oo2c-2.1.3 released

[Michael v. A. <Mic...@de...>]

(oo2c) Type conversion was done in error when passing a string
constant to a formal parameter derived from type Object.Object.  This
conversion is only possible of the formal paramter is Object.Object or
an extension of Object.String.  Due to a type check bug, string
objects could be passed to arbitrary variables, which violates the
type system and can all kinds of undesireable side effects.

(oob) Move doc comments of record types from the level of the type
declaration to the beginning of the record type.

In addition to this there are the usual number of cleanups and the
beginnings of an x86 assembler back-end.

-- mva

Re: [ooc-compiler] Size of executable

[Stewart G. <sgr...@ii...>]

Hi Frank,

The large executable is probably due to the amount of code that you are 
importing from the OOC core libraries. Under Windows, "C" programs 
dynamically link to the equivalent "libc", so they are much smaller. 
For a comparison, try the "Example4" module in the Windows package (see 
VisualOberon CVS). It uses just Windows.MessageBoxA to output a 
message. From memory, this results in an executable that is about 60K 
in size (ie. basically the size of the statically linked GC). If you 
dynamically link the GC, it should be even smaller.

Currently, there is no support for building dynamic libraries under 
Windows. Microsoft's DLLs are idiosyncratic in that they need special 
compile-time treatment for libraries and their clients (eg. the 
requirements for dllimport/dllexport attributes on imported/exported 
functions).

AFAIK, Windows DLLs are still not supported by libtool, which is OOC's 
default tool for managing shared libraries. With a few specific 
assumptions (eg. that all functions exported from modules are are 
exported from the library), it should be possible to build and use DLLs 
under Windows using just the support that is now in GCC 3.

Cheers,
   Stewart

On Tuesday, June 1, 2004, at 03:45  AM, Frank Hrebabetzky wrote:

> Finally I get my programs compiled and running and my work done. So my 
> attention is attracted by less important aspects now (no more need to 
> respond within impressive 50 min.).
>
> I compiled 'Hello world' on Win32/MinGW and got an executable of 1.3 
> MByte. Option --no-rtc had no influence. I am somewhat lost with 10 
> lines of gcc options scrolling up upon 'oo2c -Mv hello.Mod'. What is 
> happening? Everything being linked statically and the programs would 
> run on PCs without MinGW and oo2c? How could I reduce the size?
>
> -----------------------------------------------------------
> Frank Hrebabetzky		Tel.:  +55/48/239-2258
> Photonita Ltda			Fax:   +55/48/239-2200
> Parque Tec. Alfa - Ed. CELTA	email: fh...@ph...
> Florianopolis, SC		WWW:   www.photonita.com.br
> 88030-000
> Brasil
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] Undefined reference from interface module

[Stewart G. <sgr...@ii...>]

Hi August,

If you're working with OpenGL, you might like to check out my 
"quick-and-dirty" translation here:
   http://maple.murdoch.edu.au/~stewart/files/interfaces/gl/

The module GL.Mod is derived from "gl.h" and "glu.h" under Windows NT. 
It needs a some cleaning up, but should be usable. For example, there 
are numerous "AutoPtr_" declarations which are generated to remove type 
constructors in procedure declarations. These should be given names 
that are meaningful in context. I did this a while back, but never 
tested it (other than verifying that it compiles) since I eventually 
managed to do what I wanted using GDI functions. I suspect that if you 
add your "LINK LIB" declarations to the module header it will probably 
work. Either way, I'd be interested to know if you have any success 
with it.

Cheers,
   Stewart

On Friday, May 28, 2004, at 09:12  AM, August wrote:

> I'm trying to port OpenGL and GLUT to OOC. I can successfully compile 
> and
> link the following(meaningless) C-program with `gcc
> opengltest.c -lopengl32 -lglu32 -lglut32'.
>
> opengltest.c
> ------------
> #include <GL/glut.h>
> int main(int argc, char *argv[])
> {
>   glutMainLoop();
>   return 0;
> }
>
> When I try to compile `OpenGLTest.Mod' (shown below) with `oo2c -M -r 
> ..
> OpenGLTest.Mod' I get an error from the linker saying:
>
> /home/adm/ob2/lib/obj/OpenGLTest.o(.text+0x35):OpenGLTest.c: undefined
> reference to `glutMainLoop'
>
> Any ideas? Is there a way to see what `gcc' command `oo2c' invokes 
> (verbose
> option or something)?
>
> Thanks in advance,
> August
>
> Glut.Mod
> ----------
> MODULE Glut [INTERFACE "C"; LINK LIB "opengl32"; LIB "glu32"; LIB 
> "glut32"
> END];
>    PROCEDURE ["glutMainLoop"] MainLoop*();
> END Glut.
>
> OpenGLTest.Mod
> -------------------
> MODULE OpenGLTest;
>    IMPORT Glut;
> BEGIN
>    Glut.MainLoop();
> END OpenGLTest.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] Size of executable

[Michael v. A. <Mic...@de...>]

Frank Hrebabetzky <fh...@ph...> writes:

> Finally I get my programs compiled and running and my work done. So my
> attention is attracted by less important aspects now (no more need to
> respond within impressive 50 min.).
> 
> I compiled 'Hello world' on Win32/MinGW and got an executable of 1.3
> MByte. Option --no-rtc had no influence. I am somewhat lost with 10
> lines of gcc options scrolling up upon 'oo2c -Mv hello.Mod'. What is
> happening? Everything being linked statically and the programs would
> run on PCs without MinGW and oo2c? How could I reduce the size?

There are two primary techniques to reduce the size of a binary:
putting library modules into a shared library and linking the
executable dynamically against it, and removing debug information from
the executable.  I don't have any idea how the former can be achieved
under Windows.  As for the latter, running "strip" on the binary file
may do the trick.  Using "--no-rtc" may also help, but for this the
program code in question needs to be complex enough to do any run-time
checks.

-- mva

[ooc-compiler] Size of executable

[Frank H. <fh...@ph...>]

Finally I get my programs compiled and running and my work done. So my 
attention is attracted by less important aspects now (no more need to 
respond within impressive 50 min.).

I compiled 'Hello world' on Win32/MinGW and got an executable of 1.3 
MByte. Option --no-rtc had no influence. I am somewhat lost with 10 
lines of gcc options scrolling up upon 'oo2c -Mv hello.Mod'. What is 
happening? Everything being linked statically and the programs would run 
on PCs without MinGW and oo2c? How could I reduce the size?

-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA	email: fh...@ph...
Florianopolis, SC		WWW:   www.photonita.com.br
88030-000
Brasil

[ooc-compiler] oo2c-2.1.2 released

[Michael v. A. <Mic...@de...>]

(PROBLEMS) Added workaround for IRIX 5.3 readdir_r().

(oo2c) Change evaluation of procedure argument to "right to left".
Matching the C calling conventions like this provides a >2% speedup to
the compiler executable.

(oo2c) Check that the length of an `ARRAY n OF' definition is a
constant expression.

(oo2c) Apply constant folding to set comparison.  (bug #958967)

(Object:BigInt) x.Equals(NIL) is always FALSE.

-- mva

Re: [ooc-compiler] VisualOberon or not VisualOberon?

[Frank H. <fh...@ph...>]

Thanks for your detailed answer, Tim.

The point which let me think most, is about the size of the development 
groups. I knew that they are small, but I didn't expect thus few people 
in the case of oo2c.

The language decision is a hard one, once you are addicted to elegance 
(which according to Saint Exupery is reached not when there remains 
nothing to be added, but when there remains nothing to be left out), you 
have found it, and the tool for writing executables for the two 
dominating OSs worldwide depends on a single man.

With respect to GUI building, I'll try to postpone the decision as much 
as possible, following the MVC (model-viewer-controller) paradigm as 
long as possible, using the following strategy: writing programs which 
allow full control through command line parameters/options, compile them 
into an executables, and call them later from the GUI. It may still take 
some time, but you made me curious about VO, so I'll have a look at it.

-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA
Florianopolis, SC
88030-000
Brasil

Re: [ooc-compiler] Undefined reference from interface module

[Michael v. A. <Mic...@de...>]

"August" <fus...@sp...> writes:

> I'm trying to port OpenGL and GLUT to OOC. I can successfully compile and
> link the following(meaningless) C-program with `gcc
> opengltest.c -lopengl32 -lglu32 -lglut32'.
> 
> opengltest.c
> ------------
> #include <GL/glut.h>
> int main(int argc, char *argv[])
> {
>   glutMainLoop();
>   return 0;
> }
> 
> When I try to compile `OpenGLTest.Mod' (shown below) with `oo2c -M -r ..
> OpenGLTest.Mod' I get an error from the linker saying:
> 
> /home/adm/ob2/lib/obj/OpenGLTest.o(.text+0x35):OpenGLTest.c: undefined
> reference to `glutMainLoop'
> 
> Any ideas? Is there a way to see what `gcc' command `oo2c' invokes (verbose
> option or something)?

Use --verbose or -v to see the shell commands.  The modules you
provide below should link against all three libraries.

-- mva

> 
> Thanks in advance,
> August
> 
> Glut.Mod
> ----------
> MODULE Glut [INTERFACE "C"; LINK LIB "opengl32"; LIB "glu32"; LIB "glut32"
> END];
>    PROCEDURE ["glutMainLoop"] MainLoop*();
> END Glut.
> 
> OpenGLTest.Mod
> -------------------
> MODULE OpenGLTest;
>    IMPORT Glut;
> BEGIN
>    Glut.MainLoop();
> END OpenGLTest.

[ooc-compiler] Undefined reference from interface module

[August <fus...@sp...>]

I'm trying to port OpenGL and GLUT to OOC. I can successfully compile and
link the following(meaningless) C-program with `gcc
opengltest.c -lopengl32 -lglu32 -lglut32'.

opengltest.c
------------
#include <GL/glut.h>
int main(int argc, char *argv[])
{
  glutMainLoop();
  return 0;
}

When I try to compile `OpenGLTest.Mod' (shown below) with `oo2c -M -r ..
OpenGLTest.Mod' I get an error from the linker saying:

/home/adm/ob2/lib/obj/OpenGLTest.o(.text+0x35):OpenGLTest.c: undefined
reference to `glutMainLoop'

Any ideas? Is there a way to see what `gcc' command `oo2c' invokes (verbose
option or something)?

Thanks in advance,
August

Glut.Mod
----------
MODULE Glut [INTERFACE "C"; LINK LIB "opengl32"; LIB "glu32"; LIB "glut32"
END];
   PROCEDURE ["glutMainLoop"] MainLoop*();
END Glut.

OpenGLTest.Mod
-------------------
MODULE OpenGLTest;
   IMPORT Glut;
BEGIN
   Glut.MainLoop();
END OpenGLTest.

Re: [ooc-compiler] Foreign module compilation

[Frank H. <fh...@ph...>]

Michael van Acken wrote:
> The shell commands generated by oo2c do not quote arguments with
> spaces.  The effect is that gcc sees a garbled command line.  This is
> a known problem.  Please use a working directory without any spaces in
> its path.

My empty foreign module "Serial" compiles now, thanks.

Next question: Serial.Mod contains a global variable, "VAR erc*: 
INTEGER" which shall receive an error code. The only similar thing I 
found in the corresponding c file is "OOC_INT16 Serial__erc". If I don't 
touch it, everything goes well. When I assign it a value, I get a 'parse 
error before "=" token'. So how can I assign a value to an exported 
variable?
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA	email: fh...@ph...
Florianopolis, SC		WWW:   www.photonita.com.br
88030-000
Brasil

Re: [ooc-compiler] VisualOberon or not VisualOberon?

[Tim T. <ra...@ed...>]

Hallo!

> I certainly will need GUIs, so should I use VisualOberon or another=20
> framework (Glade/Gtk, Qt, ...)?

That depends. If you choose anything other than VisualOberon and want to =

use oo2c you must write the necessray foreign or interface modules. This =

is possible for GTK, since it is C based, but is very difficult for Qt,=20
since it is C++.

GTK is nice to use, but at least the 1.X were not that nice to program.=20
2.x is likely better, but it is also likely that you quickly want to=20
write some OO layer on top of it (like the C++ bindings for GTK), you=20
hide all that lengthy and crytic procedure names. So a lot of effort.

So if you want to use oo2c VO has some initial benefit ;-)

> I know the Oberon look-and-feel from System 3 and I like it. And using =


VisualOberon is themeable. While themability is not perfect it should be =

possible to simulate the look of Oberon System if that is a problem for y=
ou.

> the language Oberon for the GUI would make programming more comfortable=
=20
> using VisualOberon. On the other hand: VO (i) would have to be=20

I personally think that VisualOberon is simple to use if you have=20
understood some basic concepts.

> statically linked to my programs or be installed on the target=20
> platforms, whereas Gtk already might be there. (ii) More people are=20

Yes. VisualOberon is still in development phase and API changes are=20
likely. So eitehr you build versioned packages are better use a static=20
library (not that the binary sice can be drastically reduced if you=20
switch of run time checks). Versioning of GTK is definitely better.

> familiar with C and Gtk. And finally: (iii) for Gtk an interface builde=
r=20

It is your program. Why should you bother what other people like?

> is available (Glade). So I tend towards the latter solution.

You do not need an interface builder for VisualOberon. In fact IMHO=20
interface builder stoped progress of GUI technics. You should try=20
VisualOberon to know what I mean. VisualOberon also supports XML=20
description files (VGD) which seems to be the future (Avalon ;-)). And=20
if you like you can still write a GUI builder for VO ;-)

You havn't mention the real problems of developing with VisualOberon.=20
oo2c and VisualOberon are both a one man show. If one of them stops=20
their work you are in problems if you want bugfixes or new features -=20
unless you take over development.

VisualOberon is not that feature rich as GTK or QT are. The reason for=20
this is not bad design but lack of help. It is likely that if Microsoft=20
or Apple release their next generation OS and Gnome and KDE further=20
develop VisualOberon will fall back since I cannot compete with hundreds =

of developers. Interfacing to third party library is a help but not=20
everything is easy to integration (try write a HTML control for VO based =

on the Mozilla engine!). That still means that you can program nice and=20
smart GUIs and if you are missing a control that should be easy to add=20
but you won't get transparency, animations, HTML stuff, Richtext=20
control, OO database, CORBA, SOAP, webservices or .NET support. But that =

is a problem that otehr plattform independent GUI libraries share, it is =

just that they have more developers to compensate.

> I am curious about your ideas out there, and especially about the=20
> objective opinion of Tim ;-)

I tried by best :-)

--=20
Gru=DF...
        Tim.

Re: [ooc-compiler] Oberon-2 standard

[August <fus...@sp...>]

> Don't get
> too impressed with the word "standard".  Oberon (which was hardware,
> operating system, and programming language in the beginning) was, and
> probably still is, a vehicle for research and teaching -- but not for
> "standards".

I can't see why the popular conclusion "the language is not complicated
enough, so it can't be a production language" should hold true. Apart from a
small (maybe toy) library "The Oakwood Guidelines for Oberon-2 Compiler
Developers" also discusses interrupt and code procedures, interfacing to
external languages and compilation control. With these additions the
language should be just as much a production language as e.g. C.

> All programms I have seen that were both Oakwood compatible and
> portable were either student exercises or toy programs.  To have a
> program that runs both on the original Oberon System and in an
> environment like Unix is a challenge.

As far as I know the Oakwood report discusses a standard for compiler
writers, not for Oberon operating system developers. Regarding the Oakwood
modules my point is that OOC are free to choose *any* names for its modules
but the eight ones "reserved" by the Oakwood standard.
Why then choose some of these names (`In', `Out', `Files' and `Strings') for
non-compatible modules and cause confusion?

> It is pretty safe to assume that there are very few users that program
> for the Oakwood guidelines.

Maybe that has to do with the fact that there is no (as far as i know) fully
Oakwood compliant compiler (outside the Oberon OS).

-- August

Re: [ooc-compiler] Foreign module compilation

[Michael v. A. <Mic...@de...>]

Frank Hrebabetzky <fh...@ph...> writes:

> Tim Teulings wrote:
> > So you try to use your FOREIGN module as application main module?
> > Possibly oo2c canot handle it. Try to make a separate, "normal"
> > module that imports your FOREIGn module and use that as program
> > module.
> 
> Did that and reduced all files to a minimum. Now my actual directory
> contains an executable module test.Mod which imports the foreign
> module Serial.Mod, the implementation of which is Serial.c:

> [...]
> gcc -O2 -I/usr/local/include -DGC_WIN32_THREADS
> -I/usr/local/lib/oo2c/src -Iobj -I/usr/local/lib/oo2c/obj
> -c /Documents and Settings/Frank/Documents/Test/Serial.c
> -o obj/Serial.o
> gcc: cannot specify -o with -c or -S and multiple compilations

The shell commands generated by oo2c do not quote arguments with
spaces.  The effect is that gcc sees a garbled command line.  This is
a known problem.  Please use a working directory without any spaces in
its path.

-- mva