[M3devel] "target specific pragmas"?

[Jay]

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 maintainability.
A lot of #if here there and everywhere of course can have the opposite effect.
And I realize if you were to drop support for a target, it is easier to find/delete files/directories than #ifs, but I don't think that's a good enough reason to sway the decision.
It goes both ways.
 
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 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. 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 all the right capabilities for this. Type forwarding, sure. But how about procedure forwarding? Like nt386\cstdio.i3 fopen = common\ccommonstdio.i3 fopen? And having to duplicate a line per type/procedure is lame anyway, you KIND OF want "module inheritance". However, if you allow preprocessing based on target, perhaps the need for that goes away.
 
While extern C varargs functions are generally useless in Modula-3, and therefore extern __cdecl is fairly rare, it DOES occur when you write little helpers in C, such as for errno.
 
A good /heuristic/ might be to change the default in any directory that has no c_source.
But it is only heuristic.
 
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.
 
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 ugly 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.
 
I really believe this is highly highly unlikely to occur, and it is not a terrible outcome, and this bridge could be crossed in the far off future.
The functions that are usually in need of calling conventions are usually only present on one system.
Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly nonexistant.
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 :) )
 
 
 - Jay



> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 2008 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 option 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 12/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this through.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good > >> idea.> >>> >> Something like either the ability to prefix pragmas with a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Something like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worms.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expressions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >> etc.> >>> >> I don't really have enough interest here to work through this, > >> just sending out the bait...> >>> >> Obviously this was triggered by 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 going 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 programming was common, more > >> people knew more lower level details and playing games with > >> calling conventions was something anyone could do. Most other > >> current systems are rooted in C programming. Working in C, calling > >> conventions are generally in a hidden layer below what anyone > >> thinks about. Therefore, the smaller number of capable people > >> working at that level have the good sense to only have one calling > >> convention. No more systems will evolve from "small", at least not > >> without having observed this history. Therefore, there will no > >> longer be multiple calling conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is > >> only x86> 
_________________________________________________________________
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/9fbd420e/attachment-0002.html>