<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Mika good point, I know that, forgot, thanks for reminding me.<BR>
One of the interesting things about Modula-3, or rather anything but C and C++, is easy parsing, easy building of other tools.<BR>
<BR>
Just to be clear though, independent of my crazy ideas, such tools can't just enumerate a source tree. I <EM>guess</EM> they should operate over the pkg tree? You know, they can't understand the source tree without understanding m3makefiles.<BR>
<BR>
I started a little experiment here.<BR>
I added m3-libs/m3core/src/C/common/Cstdio.i3.<BR>
This is a file that ought to be nearly identical for all targets. For now I only changed NT386.<BR>
I'm thinking either:<BR>
a) I'm not quite on base and just fork it per-target, as it was<BR>
b) provide a little bit of C code with #ifdefs, like making the SEEK_* constants into VARs and using C to initialize them. That's a bit of a downer though, since constants ought to be constants.<BR>
c) factor it somehow as I was alluding, like, well, again I'm not sure Modula-3 has what I'd want here, but at least for types and constants, you can push the non-portable stuff into Ctargetstdio.i3 and then expose them in Cstdio.i3, forking only Ctargetstdio.i.<BR>
<BR>
I'll explain so I can get my question in. :)<BR>
<BR>
I understand, say:<BR>
<BR>
Ctargetstdio.i3 (* one of these per target, with not much content *) <BR>
CONST<BR>
SEEK_CUR = ..; (* target specific probably *) <BR>
SEEK_SET = ..; ditto <BR>
SEEK_END = ..; ditto <BR>
TYPE<BR>
FOO = ... ditto <BR>
<BR>
Cstdio.i3 (* portable *) <BR>
CONST<BR>
SEEK_CUR = Ctargetstdio.SEEK_CUR;<BR>
SEEK_SET = Ctargetstdio.SEEK_SET;<BR>
SEEK_END = Ctargetstdio.<FONT face="">SEEK_END</FONT>;<BR>
TYPE<BR>
FOO = Ctargetstdio.FOO;<BR>
<BR>
FILE = UNTRACED REF RECORD END;<BR>
<BR>
<extern> procedure fopen(a: const_char_star; b: const_char_star): FILE;<BR>
<BR>
It is tedious but I believe it works.<BR>
It'd be nice, I think, if every symbol in one interface could be automatically aliases/exposed in another.<BR>
At least for this purpose, maybe not for any other. I'm speculating here, so please respond kindly. :)<BR>
The non portable types and constants can be pushed out and then reexposed as if they were portable and in one place.<BR>
<BR>
However, let's say, for argument/question's sake, that some function accepts int on some targets, off_t on another.<BR>
Nevermind for now how you can portably call it.<BR>
<BR>
Ctargetstdio.i3 (* one of these for every target, but another question in a sec ... *)<BR>
<BR>
<extern> PROCEDURE seeksomething(a: off_t); let's say it is int on some platforms.<BR>
<BR>
Cstdio.i3 (* the portable one *)<BR>
<BR>
seeksomething = Ctargetstdio.seeksomething; does this work? I should try it out, read the docs.<BR>
<BR>
But then the next question would be, let's say there's 20 platforms and 5 use off_t and 15 use int.<BR>
It's unfortunate if I have to repeat the content 20 times when there are only two variants.<BR>
You can see this kind of thing where sometimes we include_dir(TARGET), sometimes include_dir(OS_TYPE).<BR>
OS_TYPE implies less work, nice.<BR>
<BR>
Perhaps concatening stuff in arbitrary way with Quake really is the way?<BR>
It seems almost sarcastic, but perhaps not.<BR>
<BR>
As long as the pkg store is easily parsed?<BR>
(There's a setting to ship implementation files. I guess that must be left on? I thought it'd be nice to reduce distribution size..)<BR>
<BR>
But for that matter --- <IF_TARGET> could be processed by the compiler and result in a file with it already accounted for and ship that. Isn't that just as good? EXCEPT that more thought would have to go into the spec, whereas m3makefile is already a general purpose system that anyone can do anything with?<BR>
<BR>
??<BR>
<BR>
- Jay<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 />Climb to the top of the charts! Play the word scramble challenge with star power. <a href='http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan' target='_new'>Play now!</a></body>
</html>