[M3devel] "target specific pragmas"?

[Jay]

Mika good point, I know that, forgot, thanks for reminding me.
  One of the interesting things about Modula-3, or rather anything but C and C++, is easy parsing, easy building of other tools.
 
Just to be clear though, independent of my crazy ideas, such tools can't just enumerate a source tree. I guess they should operate over the pkg tree? You know, they can't understand the source tree without understanding m3makefiles.
 
I started a little experiment here.
I added m3-libs/m3core/src/C/common/Cstdio.i3.
This is a file that ought to be nearly identical for all targets. For now I only changed NT386.
I'm thinking either:
   a) I'm not quite on base and just fork it per-target, as it was
   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.
   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.
 
I'll explain so I can get my question in. :)
 
I understand, say:
 
Ctargetstdio.i3 (* one of these per target, with not much content *) 
CONST
  SEEK_CUR = ..; (* target specific probably *) 
  SEEK_SET = ..; ditto 
  SEEK_END = ..; ditto  
TYPE
  FOO = ... ditto  
 
Cstdio.i3 (* portable *) 
 CONST
  SEEK_CUR = Ctargetstdio.SEEK_CUR;
  SEEK_SET = Ctargetstdio.SEEK_SET;
  SEEK_END = Ctargetstdio.SEEK_END;
TYPE
  FOO = Ctargetstdio.FOO;
 
FILE = UNTRACED REF RECORD END;
 
<extern> procedure fopen(a: const_char_star; b: const_char_star): FILE;
 
It is tedious but I believe it works.
It'd be nice, I think, if every symbol in one interface could be automatically aliases/exposed in another.
  At least for this purpose, maybe not for any other. I'm speculating here, so please respond kindly. :)
The non portable types and constants can be pushed out and then reexposed as if they were portable and in one place.
 
However, let's say, for argument/question's sake, that some function accepts int on some targets, off_t on another.
Nevermind for now how you can portably call it.
 
Ctargetstdio.i3 (* one of these for every target, but another question in a sec ... *)
 
<extern> PROCEDURE seeksomething(a: off_t);  let's say it is int on some platforms.
 
Cstdio.i3 (* the portable one *)
 
seeksomething = Ctargetstdio.seeksomething;    does this work? I should try it out, read the docs.
 
But then the next question would be, let's say there's 20 platforms and 5 use off_t and 15 use int.
It's unfortunate if I have to repeat the content 20 times when there are only two variants.
You can see this kind of thing where sometimes we include_dir(TARGET), sometimes include_dir(OS_TYPE).
OS_TYPE implies less work, nice.
 
Perhaps concatening stuff in arbitrary way with Quake really is the way?
It seems almost sarcastic, but perhaps not.
 
As long as the pkg store is easily parsed?
(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..)
 
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?
 
??
 
 - Jay



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