[M3devel] determing current processor as string

[Tony Hosking]

Hmm.  I'm not sure I know what all the implications are to have an  
opinion.

On 5 Jan 2009, at 12:23, Jay wrote:

> Sorry, I had a tangent there.
> The main question was regiarding a library feature, not a compiler  
> issue.
>
>
>   libm3/src/os/POSIX/OSConfigPosix.m3
>   libm3/src/os/POSIX/OSConfig.i3
>   libm3/src/os/WIN32/OSConfigWin32.m3
>   libm3/src/os/WIN32/OSConfig.i3
>
> The bulk of this code is never used in the cm3 tree anyway.
>
> The tangent was regarding "cm3 -dump-host" or such, though it's more  
> complicated maybe. Some hosts are "biarch" or "multiarch".
>
>  - Jay
>
>
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] determing current processor as string
> Date: Mon, 5 Jan 2009 12:12:56 +1100
>
>
> As far as I am concerned I think PPC or PowerPC is sufficient, since  
> the gcc-based backend figures out what it needs.  Why would the  
> front-ends need to know?  Perhaps I am missing your point...
>
> On 5 Jan 2009, at 09:57, Jay wrote:
>
> Thoughts here?
>
>
> Does the processor need to be "friendly" and "precise" including stuff
> not knowable at compile time (386 vs. 486 vs. 586, etc.),
> or would just "PowerPC" or "PPC" suffice?
>
>
> This question affects the Posix code.
>
>
> The Posix code tries to fetch some data at runtime from uname, and  
> if that fails
> it falls back to built in data. Besides that the data is used in an  
> unlikely
> error path, we bother carrying the data for all systems, which afaik
> is completely unnecessary. Once I confirm, I'll have Quake generate
> just what is needed.
>
>
> Similarly, I think cm3 should have -print-host or somesuch.
> Then the platform probing in sysinfo.sh could probably all go away.
> (Except for my idea of /cm3/bin/cm3.sh that calls /cm3/bin/target/ 
> cm3.)
>
>
> There is more here than just the processor.
> So some runtime code would remain, even if the processor
> became hard coded at compile time.
>
> You know, there are a few models here:
>
>   Use data at runtime asis.
>     e.g. GetEnv("PROCESSOR_ARCHITECTURE") and be done.
>     Does that work on CE?
>
>   Build-in the data at compile time and be done.
>      This requires possibly a revisit for every port, but simple.
>       It goes obsolete in time, but not quietly, it'd be an error in  
> the Quake code
>           when a new platform is introduced.
>      Or, if the string is just <TARGET> then automatically ports, no  
> revisit.
>      This doesn't have the concern "does it work on CE?" or
>        of Posix vs. Win32 portability.
>
>   Use data at runtime to pick among compile time data.
>      This is the current approach and it goes obsolete quietly in  
> time.
>
>
> As well, these functions are never even used that I can see.
> Remove them?
> Or assume they might be used outside the cm3 tree?
>
> (That's quite a "line" in decision makiing. It's so much nicer
> to assume/know you have all the relevant code visible and therefore
> can make any change, provided you fix the client code, vs. having to
> assume there is "anything" out there.)
>
>  - Jay
>
>
> > Date: Fri, 2 Jan 2009 21:22:55 +0000
> > To: m3commit@
> > From: jkrell@
> > Subject: [M3commit] CVS Update: cm3
> >
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 09/01/02 21:22:55
> >
> > Modified files:
> > cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3
> >
> > Log message:
> > add in some missing architectures, though arguably this should be  
> either GetEnv(PROCESSOR_ARCHITECTURE) (does it work on CE?) or a  
> constant determined at build time; the historical code goes obsolete  
> automatically and quietly
> >
>
>
>

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