[M3devel] determing current processor as string

[Jay]

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.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] determing current processor as stringDate: 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 stuffnot 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 failsit falls back to built in data. Besides that the data is used in an unlikelyerror path, we bother carrying the data for all systems, which afaikis completely unnecessary. Once I confirm, I'll have Quake generatejust 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 processorbecame 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 nicerto assume/know you have all the relevant code visible and thereforecan make any change, provided you fix the client code, vs. having toassume 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/5e5c3891/attachment-0002.html>