[M3devel] how to switch between user and kernel threads..

[Tony Hosking]

We do get inlining within modules by virtue of the gcc-backend at -O3.

On 15 Jan 2009, at 14:03, Jay wrote:

> The installer?
> I thought the granularity was at the time of linking an executable.
> I personally thought a command line parameter would be reasonable.
>
>
> Why not function pointers?
> It is a simple straightforward method to implement.
> It should add one instruction per call.
> It does reduce inlinability but I'm sure we aren't getting any such  
> such inlinability anyway.
> Dynamic linking already kills inlinability, as does separate  
> compilation of modules in most systems.
>
>
> I'm not sure how the types work out in such a scheme, but probably  
> assuming Thread.T is already a reference type, it can become ADDRESS  
> and then loopholed to ThreadPosix.T or ThreadPThread.T.
>
>
> Function pointers are also the easiest method to build. I'm not sure  
> what the others are.
> I can try making m3-libs/m3coreuserthreads that contains only  
> m3makefiles.
> Probably it can say:
> LibraryName = "m3coreuserthreads"
> include_dir("../m3core/m3makefile")
>
>
> and m3core/m3makefile can say
> if not defined("LibraryName")
>   LibraryName = "m3core"
> end
> Library(LibraryName)
>
>
> If that works, not bad.
>
>
> And then cm3 or the config file can translate m3core to  
> m3coreuserthreads at some point.
>
>
>  - Jay
>
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Thu, 15 Jan 2009 11:31:17 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] how to switch between user and kernel threads..
>
>
> No function pointers please.  Let the installer decide whether to  
> use native or user threads.
>
> On 15 Jan 2009, at 08:30, Jay wrote:
>
> I'll wait.
> So, build two different m3core.lib/a/so/dylib?
> m3core and m3coreuserthreads
>
> Compile both thread directories, if the platform supports it, and
> call quake make_lib twice with slightly different parameters?
> An m3core specific hack in the config file or cm3?
> Easy enough in the config file.
> Very m3core specific.
> I suppose you could argue that quake isn't a generic build system,
> but it is Modula-3's build system, and that m3core is really special.
>
> The result btw, would likely be no change at all to any *.i3 or *.m3  
> file.
>
> I still think function pointers are the way to go.
> Even with function pointers, the changes to *.i3 and *.m3 would be  
> very minor.
> Just the export list would vary.
> And new *.i3 files introduced.
>
>  - Jay
>
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Wed, 14 Jan 2009 21:31:22 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] how to switch between user and kernel threads..
>
> I don't want dynamic switching.  A link-time switch is just fine.
>
> Also, please don't go messing about with this right now -- I have  
> changes pending for the threads system that will be harder to  
> integrate if you change with it further.
>
> On 14 Jan 2009, at 20:14, Jay wrote:
>
> Are people really against using function pointers for this?
> Either changing the interface to have function pointer variables  
> (I'm not sure Modula-3 allows this, but in C you can fairly  
> transparently replace functions with function pointers; client code  
> just keeps working; it breaks down in C++ with overloading), or  
> having a set of functions that just call/jump through function  
> pointers? There would be no if, no conditional branches.
>
> Dynamic linking on Windows always goes through function pointers  
> already.
>  So while yes it adds another instruction, it is already never  
> getting inlined.
> Don't other platforms do that too?
> Or they patch every call site?
>
> I'm not sure otherwise of a simple method.
> Easiest might be to have a parallel directory structure to m3core,  
> with just m3core files.
> That would wastefully rebuild all of m3core a second time, for just  
> a small amount of variation.
>
> I think function pointers are the way to go here.
>
>  - Jay
>
>
>
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090115/5992365a/attachment-0002.html>