[M3commit] libgcc.c

[Jay K]

Daniel, please look at the file.

 

 

If you write the following sorts of Modula-3 code:

 

PROCEDURE Add64(a,b: LONGINT):LONGINT= RETURN a + b; END Add64;

PROCEDURE Mult64(a,b: LONGINT):LONGINT= RETURN a * b; END Mult64;

PROCEDURE Div64(a,b: LONGINT):LONGINT= RETURN a / b; END Div64;


 

Or the following sorts of C code:


long long add64(long long a, long long b) { return a + b; }

long long mult64(long long a, long long b) { return a * b; }

long long div64(long long a, long long b) { return a / b; }

 

fanything that does these operations, not just functions that /only/ do them,

 


on some architectures (esp. 32 bit ones), the backend (or C compiler)

will emit function calls.

 

 

If gcc is the compiler/linker, it always throws libgcc.a or such,

and the functions are resolved.

 

 

Any C code has this property.

libgcc.a is liberally licensed.

Again, any C code possibly links in this code.

 

 

On systems where m3cg is the backend but gcc is not the compiler/linker,

e.g. SOLsun, you don't get libgcc.a, but you still get these function calls.

 

 

Therefore, on a platform like SOLsun, the solution is write

functions very much like the above, but with names that

match what the backend emits.

 

 

In fact, what might occur is Sun CC emits function calls

to functions with yet other names. That's awfully inefficient

(two function calls to do a multiply) but it does work.

 

 

It might be good if we could teach m3cg about the function names

used by other compilers/runtimes.

 

 

 

But it's also probably only a problem on 32bit platforms and they are the past.

 

 

Apparently there is some doubt as to if these functions are needed on 64bit platforms,

as you can see in the comments (at least in the original).

 

 

 - Jay

 
> Date: Wed, 23 Dec 2009 03:42:24 +0000
> From: dabenavidesd at yahoo.es
> To: m3commit at elegosoft.com; jkrell at elego.de
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> 
> Hi all:
> forgive my ignorance about the actual changes going on below copied M3commit message of Monday, December 21, 16:00:40 but what is this to have gcc code inside the compiler libs, I recommend to check the strict rules about this before performing such changes, Is there any problem getting gcc code inside the runtime libraries, even if this only used in level C code, this gets more C dependences in non-M3 code we are not able to guarantee, better UNSAFE than totally unmarked unsafe again. If this is not the case, and just a piece of m3cc related code I don't disqualify it yet.
> Thanks in advance 
> 
> --- El lun, 21/12/09, Jay Krell <jkrell at elego.de> escribió:
> 
> > De: Jay Krell <jkrell at elego.de>
> > Asunto: [M3commit] CVS Update: cm3
> > Para: m3commit at elegosoft.com
> > Fecha: lunes, 21 de diciembre, 2009 11:00
> > CVSROOT: /usr/cvs
> > Changes by: 
> > jkrell at birch. 09/12/21 16:00:40
> > 
> > Modified files:
> > cm3/m3-libs/m3core/src/Csupport/libgcc/:
> > libgcc.c 
> > 
> > cm3/m3-libs/m3core/src/runtime/ALPHA_OSF/: RTStackC.c 
> > cm3/m3-libs/m3core/src/runtime/DS3100/:
> > RTStackC.c 
> > cm3/m3-libs/m3core/src/runtime/POSIX/:
> > RTOSbrk.c RTOSmmap.c 
> > cm3/m3-libs/m3core/src/runtime/SOLgnu/:
> > RTStackC.c 
> > cm3/m3-libs/m3core/src/runtime/SOLsun/:
> > RTStackC.c 
> > cm3/m3-libs/m3core/src/runtime/WIN32/:
> > RTOSc.c 
> > 
> > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c 
> > 
> > Log message:
> > add mising #ifdef cplusplus extern "C" {
> > }
> > 
> > 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20091223/52219b3a/attachment-0002.html>