<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Mika, I'm not going to change the default calling convention. Don't worry.<BR>
At "best", try it out, measure it, and then provide pragmas/command line switches if folks want largescale change, but never by default, and even command line switch could be dangerous..the safe form is it'd only affect implemented implementation in a directory with a particular m3makefile directive, it would not affect imported implementations.<BR>
And this is way way way down any nonexistant list..<BR>
<BR>
Probably more interesting than more efficient but "canonical" calling conventions is "whole program optimization" like cross "module (source file) inlining, custom calling conventions, cross function constant propagation, etc. Stuff all left to gcc. :)<BR>
<BR>
Moving to AMD64 will make this go away quite nicely.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> To: jayk123@hotmail.com<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] "target specific pragmas"? <BR>> Date: Tue, 12 Feb 2008 04:56:02 -0800<BR>> From: mika@async.caltech.edu<BR>> <BR>> <BR>> Can you just generate the Modula-3 code you want using a Python<BR>> script or COBOL or whatever you like instead of trying to foist<BR>> preprocessing nastiness on innocent users of high-level Modula-3?<BR>> <BR>> Preprocessing is super nasty. It's not just a question of human<BR>> readability. m3tk has to be able to read the code, too. I should<BR>> be able to write a program that reads in (using m3tk) an arbitrary<BR>> Modula-3 interface and understands it to the point that it can<BR>> generate Network Object stubs, inter-language call stubs, etc. The<BR>> stubs should ALSO be human- and m3tk-readable after the transformation!<BR>> This should work even if the programmer has been very "clever" in<BR>> his use of Modula-3 constructs. (Just try getting something like<BR>> that to work with C or C++... it's hopeless once the preprocessor<BR>> gets involved, and possibly before.)<BR>> <BR>> Also if I may make a little request, if at all possible, please try<BR>> not to break binary compatibility with gcc-compiled C and Fortran<BR>> on NT386GNU (not sure if your ideas about calling conventions could<BR>> possibly do that...)<BR>> <BR>> Mika<BR>> <BR>> Jay writes:<BR>> >--_8b04f633-e2a4-411d-940a-739ab79b0616_<BR>> >Content-Type: text/plain; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> >I insist that it depends.<BR>> >Putting every platform-specific piece of code in its own file/directory can=<BR>> > lead to mass duplication of nearly identical code.<BR>> >Sometimes an #if here or there goes very far in /improving/ code maintainab=<BR>> >ility.<BR>> >A lot of #if here there and everywhere of course can have the opposite effe=<BR>> >ct.<BR>> >And I realize if you were to drop support for a target, it is easier to fin=<BR>> >d/delete files/directories than #ifs, but I don't think that's a good enoug=<BR>> >h reason to sway the decision.<BR>> >It goes both ways.<BR>> >=20<BR>> >Yes, you could endeavor factor things down so that everything common is in =<BR>> >common, and everything not-common is in platform-specific. But this is inad=<BR>> >equate I think. The tail is wagging the dog unnecessarily I think. If my co=<BR>> >de very nearly all goes together, don't make me separate it. Also sometimes=<BR>> > a different factoring is "encouraged" for other reasons, to match someone =<BR>> >else's factoring. Look at the C*.i3 files. They actually can be almost all =<BR>> >be nearly the same, yet they are hardly shared at all. I realize you could =<BR>> >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=<BR>> >l the right capabilities for this. Type forwarding, sure. But how about pro=<BR>> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=<BR>> >pen? And having to duplicate a line per type/procedure is lame anyway, you =<BR>> >KIND OF want "module inheritance". However, if you allow preprocessing base=<BR>> >d on target, perhaps the need for that goes away.<BR>> >=20<BR>> >While extern C varargs functions are generally useless in Modula-3, and the=<BR>> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=<BR>> >elpers in C, such as for errno.<BR>> >=20<BR>> >A good /heuristic/ might be to change the default in any directory that has=<BR>> > no c_source.<BR>> >But it is only heuristic.<BR>> >=20<BR>> >Whatever is done here, some allowance should probably be made for multiple =<BR>> >calling conventions in the same file.<BR>> >Switching the default to the overwhelming majority and then annotating the =<BR>> >minority is reasonable.<BR>> >=20<BR>> >I still believe that silently ignoring calling conventions on all but NT386=<BR>> > is VERY reasonable, and that no other platform from here on out will ever =<BR>> >have calling conventions. Esp. not with the same names. When OS/FOO has the=<BR>> > FOOAPI calling convention, you can just ignore that one on all but target =<BR>> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=<BR>> >ly something like:<BR>> ><*EXTERN FOOAPI WINAPI*> fopen();<BR>> >FOOAPI for OS/FOO, WINAPI ignored.<BR>> >WINAPI for NT386, FOOAPI ignored.<BR>> >The One True Calling Convention for all others, calling convention ignored.<BR>> >=20<BR>> >I really believe this is highly highly unlikely to occur, and it is not a t=<BR>> >errible outcome, and this bridge could be crossed in the far off future.<BR>> >The functions that are usually in need of calling conventions are usually o=<BR>> >nly present on one system.<BR>> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=<BR>> >existant.<BR>> >That could be also.<BR>> >A change just for ODBC is probably not the best, though it is a very small =<BR>> >safe harmless change (I always say that :) )<BR>> >=20<BR>> >=20<BR>> > - Jay<BR>> ><BR>> ><BR>> ><BR>> >> CC: jayk123@hotmail.com; m3devel@elegosoft.com> From: hosking@cs.purdue.e=<BR>> >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=<BR>> >08 21:08:46 -0500> To: darko@darko.org> > Indeed!> > On Feb 11, 2008, at 8:=<BR>> >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=<BR>> > specific code > > should be in a separate file. I'd also like to see an op=<BR>> >tion to > > move calling conventions to the makefile rather than in pramas =<BR>> >to > > avoid having to duplicate interface files just to have a different >=<BR>> > > calling convention for a different platform.> >> > - Darko> >> >> > On 1=<BR>> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=<BR>> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=<BR>> > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=<BR>> >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=<BR>> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=<BR>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=<BR>> >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=<BR>> > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=<BR>> >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=<BR>> >> etc.> >>> >> I don't really have enough interest here to work through thi=<BR>> >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=<BR>> >y my happening into the odbc > >> directory and bringing up ignoring WINAPI=<BR>> > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> =<BR>> >This reminds me of an important point here however -- nobody else > >> is g=<BR>> >oing to make the mistake of ever having multiple calling > >> conventions. =<BR>> >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> =<BR>> >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.=<BR>> > The PC and Mac evolved from > >> "small" systems, where assembly programmi=<BR>> >ng was common, more > >> people knew more lower level details and playing g=<BR>> >ames with > >> calling conventions was something anyone could do. Most othe=<BR>> >r > >> current systems are rooted in C programming. Working in C, calling >=<BR>> > >> conventions are generally in a hidden layer below what anyone > >> thin=<BR>> >ks about. Therefore, the smaller number of capable people > >> working at t=<BR>> >hat level have the good sense to only have one calling > >> convention. No =<BR>> >more systems will evolve from "small", at least not > >> without having obs=<BR>> >erved this history. Therefore, there will no > >> longer be multiple callin=<BR>> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=<BR>> > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20<BR>> >_________________________________________________________________<BR>> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=<BR>> >r power.<BR>> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=<BR>> >n=<BR>> ><BR>> >--_8b04f633-e2a4-411d-940a-739ab79b0616_<BR>> >Content-Type: text/html; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> ><html><BR>> ><head><BR>> ><style><BR>> >.hmmessage P<BR>> >{<BR>> >margin:0px;<BR>> >padding:0px<BR>> >}<BR>> >body.hmmessage<BR>> >{<BR>> >FONT-SIZE: 10pt;<BR>> >FONT-FAMILY:Tahoma<BR>> >}<BR>> ></style><BR>> ></head><BR>> ><body class=3D'hmmessage'>I insist that it depends.<BR><BR>> >Putting every platform-specific piece of code in its own file/directory can=<BR>> > lead to mass duplication of nearly identical code.<BR><BR>> >Sometimes an #if here or there goes very far in /improving/ code maintainab=<BR>> >ility.<BR><BR>> >A lot of #if here there and everywhere of course can have the opposite effe=<BR>> >ct.<BR><BR>> >And I realize if you were to drop support for a target, it is easier to fin=<BR>> >d/delete files/directories than #ifs, but I don't think that's a good enoug=<BR>> >h reason to sway the decision.<BR><BR>> >It goes both ways.<BR><BR>> > <BR><BR>> >Yes, you could endeavor factor things down so that everything common i=<BR>> >s in common, and everything not-common is in platform-specific. But this is=<BR>> > inadequate I think. The tail is wagging the dog unnecessarily I think. If =<BR>> >my code very nearly all goes together, don't make me separate it. =<BR>> >;Also sometimes a different factoring is "encouraged" for other reasons, to=<BR>> > match someone else's factoring. Look at the C*.i3 files. They actually can=<BR>> > be almost all be nearly the same, yet they are hardly shared at all. I rea=<BR>> >lize you could also do a sort of "forwarding", though I'm not sure that Mod=<BR>> >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=<BR>> >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=<BR>> >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=<BR>> >me anyway, you KIND OF want "module inheritance". However, if you allow pre=<BR>> >processing based on target, perhaps the need for that goes away.<BR><BR>> > <BR><BR>> >While extern C varargs functions are generally useless in Modula-3, and the=<BR>> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=<BR>> >elpers in C, such as for errno.<BR><BR>> > <BR><BR>> >A good /heuristic/ might be to change the default in any directory that has=<BR>> > no c_source.<BR><BR>> >But it is only heuristic.<BR><BR>> > <BR><BR>> >Whatever is done here, some allowance should probably be made for multiple =<BR>> >calling conventions in the same file.<BR><BR>> >Switching the default to the overwhelming majority and then annotating the =<BR>> >minority is reasonable.<BR><BR>> > <BR><BR>> >I still believe that silently ignoring calling conventions on all but NT386=<BR>> > is VERY reasonable, and that no other platform from here on out will ever =<BR>> >have calling conventions. Esp. not with the same names. When OS/FOO has the=<BR>> > FOOAPI calling convention, you can just ignore that one on all but target =<BR>> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=<BR>> >ly something like:<BR><BR>> ><*EXTERN FOOAPI WINAPI*> fopen();<BR><BR>> >FOOAPI for OS/FOO, WINAPI ignored.<BR><BR>> >WINAPI for NT386, FOOAPI ignored.<BR><BR>> >The One True Calling Convention for all others, calling convention ignored.=<BR>> ><BR><BR>> > <BR><BR>> >I really believe this is highly highly unlikely to occur, and it is not a t=<BR>> >errible outcome, and this bridge could be crossed in the far off future.<BR=<BR>> >><BR>> >The functions that are usually in need of calling conventions are usually o=<BR>> >nly present on one system.<BR><BR>> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=<BR>> >existant.<BR><BR>> >That could be also.<BR><BR>> >A change just for ODBC is probably not the best, though it is a very small =<BR>> >safe harmless change (I always say that :) )<BR><BR>> > <BR><BR>> > <BR><BR>> > - Jay<BR><BR><BR>> ><BR>> ><HR id=3DstopSpelling><BR>> ><BR><BR>> >> CC: jayk123@hotmail.com; m3devel@elegosoft.com<BR>> From: hosking@c=<BR>> >s.purdue.edu<BR>> Subject: Re: [M3devel] "target specific pragmas"?<BR>&=<BR>> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500<BR>> To: darko@darko.org<BR>&g=<BR>> >t; <BR>> Indeed!<BR>> <BR>> On Feb 11, 2008, at 8:37 PM, Darko wro=<BR>> >te:<BR>> <BR>> > I think it's not a good idea. I think all platfor=<BR>> >m specific code <BR>> > should be in a separate file. I'd also like t=<BR>> >o see an option to <BR>> > move calling conventions to the makefile r=<BR>> >ather than in pramas to <BR>> > avoid having to duplicate interface f=<BR>> >iles just to have a different <BR>> > calling convention for a differ=<BR>> >ent platform.<BR>> ><BR>> > - Darko<BR>> ><BR>> ><B=<BR>> >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:<BR>> ><BR>> >=<BR>> >;> So I have NOT thought this through.<BR>> >><BR>> >>=<BR>> > I wonder if "preprocessing" dependent only on "target" is a good <BR>> =<BR>> >>> idea.<BR>> >><BR>> >> Something like either the =<BR>> >ability to prefix pragmas with a target, <BR>> >> or an "iftarget"=<BR>> > and "ifnottarget" pragma.<BR>> >><BR>> >> Something like=<BR>> > so:<BR>> >><BR>> >> <* IF_TARGET NT386 *><BR>> =<BR>> >>> <* END_IF_TARGET*><BR>> >><BR>> >><BR>>=<BR>> > >> <* IF_TARGET NT386 *><BR>> >> <* END_IF_TARGET*=<BR>> >><BR>> >> It's a small can of worms.<BR>> >> Where can=<BR>> > they be placed? Only at "global" scope? (ie: toplevel in <BR>> >>=<BR>> > an interface/module).<BR>> >><BR>> >> What about IF_OSTY=<BR>> >PE?<BR>> >> What about expressions?<BR>> >> IF_TARGET NT3=<BR>> >86 OR NTAMD64<BR>> >><BR>> >> IF_TARGET STARTS(NT)<BR>>=<BR>> >; >><BR>> >> etc.<BR>> >><BR>> >> I don't =<BR>> >really have enough interest here to work through this, <BR>> >> ju=<BR>> >st sending out the bait...<BR>> >><BR>> >> Obviously this=<BR>> > was triggered by my happening into the odbc <BR>> >> directory an=<BR>> >d bringing up ignoring WINAPI on non-NT386 or <BR>> >> prefixing c=<BR>> >alling conventions with a target.<BR>> >><BR>> >> This re=<BR>> >minds me of an important point here however -- nobody else <BR>> >>=<BR>> >; is going to make the mistake of ever having multiple calling <BR>> >=<BR>> >;> conventions. Therefore the generality of prefixing WINAPI with <BR>&g=<BR>> >t; >> NT386: is useless.<BR>> >> Unless Mac68K support is ad=<BR>> >ded.<BR>> >><BR>> >> And here is some rationale even. The=<BR>> > PC and Mac evolved from <BR>> >> "small" systems, where assembly =<BR>> >programming was common, more <BR>> >> people knew more lower level=<BR>> > details and playing games with <BR>> >> calling conventions was s=<BR>> >omething anyone could do. Most other <BR>> >> current systems are =<BR>> >rooted in C programming. Working in C, calling <BR>> >> convention=<BR>> >s are generally in a hidden layer below what anyone <BR>> >> think=<BR>> >s about. Therefore, the smaller number of capable people <BR>> >> =<BR>> >working at that level have the good sense to only have one calling <BR>>=<BR>> > >> convention. No more systems will evolve from "small", at least no=<BR>> >t <BR>> >> without having observed this history. Therefore, there =<BR>> >will no <BR>> >> longer be multiple calling conventions.<BR>> &=<BR>> >gt;><BR>> >> That is my theory at least.<BR>> >><BR>&g=<BR>> >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=<BR>> > is <BR>> >> only x86<BR>> <BR><BR><br /><hr />Climb to the top=<BR>> > of the charts!=A0Play the word scramble challenge with star power. <a href=<BR>> >=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=<BR>> >k_jan' target=3D'_new'>Play now!</a></body><BR>> ></html>=<BR>> ><BR>> >--_8b04f633-e2a4-411d-940a-739ab79b0616_--<BR><BR><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>