Public SourceMage Discussion List

[Robin Cook <rcook AT wyrms.net>]

I don't see a problem with the changes below as long as changes are made
to any spell that the missing flags would cause degradation in the use
of the program.

CuZnDragon
Robin Cook

On Mon, 2007-01-08 at 04:13 +0100, Thomas Orgis wrote:
> SMGL Archspecs: Final Notice
> *************************************
> 
> I think especially with all the testing being due for the next stable,
> this now would be the last opportunity to get the long-awaiting new
> archspecs out.
> Perhaps it is too late already and this call is going out for test
> grimoire only, but there is this list of issues that await resolution
> for quite some time, linked on
> 
> http://bugs.sourcemage.org/show_bug.cgi?id=13240
> 
> The archspecs are a core thing that deserves both getting that fixes
> and being well-tested... 
> I ask for the public opinion on
> 
> a) if we should push the 0.7 for the upcoming stable
> 
> b) the last questions about them that bother me:
>       1. Do we need to introduce extra minimal archspecs or just
>       replace the "main" ones?
>       For explanation: minimal archspec means dropping all -mmx
>       -m3dnow and similar flags when -march already includes them.
>       I am in favor of dropping these extra flags in the main specs.
> 
>       2. Related but special, perhaps: Should archspecs include
>       -mfpmath=sse per default? Some say it's super-cool, others say
>       it depends. I guess others are right.
>       I just tested with my Pentium-M laptop; decoding time with
>       mpg123. Plain -march=pentium-m wins against added -mfpmath=sse,
>       where an additional -msse does not make any difference.
>       It looks like SSE fpmath sucks a bit here, and thus is not
>       enabled by the -march -- it _is_ enabled for x86_64, though. I
>       vote for omitting it and so let users add it if they really
>       mean it. We should give a sane default with no experiments.
> 
>       3. -m64 for 64 bit arch? Is not needed because 64 bit compiler
>       defaults to it anyway. It was noted that some spell may depend
>       on this to properly fail if it only can work with 32 bits (wine?). I
>       say the info is in CHOST and the SMGL_COMPAT_ARCHS array - 
>       make the spell use it. It was also noted that this flag may hinder
>       compilation of 32bit stuff (when we support 64 and 32bit compiler).
> 
> We have a lot of needed fixes in these archspecs and I really would
> like to see them out in the world. Can we settle on some decision on
> the 3 issues presented here? Especially for the second one, I don't
> want to introduce the extra minimal archspecs when we possibly drop
> them by merging them into the main ones shortly after that.
> 
> In any case, when we eventually ship a stable grimoire with updated
> archspecs, we should make sure that people cast the archspecs first and
> double-check their optimization settings in sorcery _before_ casting
> anything else.
> 
> I'll wait some time for answers here, but I am tempted to get the new
> archspecs to test and wait for bug reports;-)
> Hm, but you don't have to worry too much about that yet since I don't
> have means/authority to prepare and properly sign/upload an archspecs
> tarball (lynx...?).
> 
> See
> Bug that triggered the questions part:
> http://bugs.sourcemage.org/show_bug.cgi?id=10198
> 
> Btw, looking at 
> http://blog.gmane.org/gmane.linux.gentoo.devel/day=20061015
> tells something about the sse thing and also about the sad fact that I
> cannot even spot an intel core archspec yet. These are quite widespread
> among ppl that actually buy _new_ hardware... we have some?
> 
> 
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>

Attachment: signature.asc
Description: This is a digitally signed message part