Re: [AD] proposing a new official .lib name for VC static CRT version

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


I welcome our c-only overlords!
Death to the ASM ! Less ASM = more portable... one of allegros goals is to be cross-platform (portable).

Removing dependancies on mingw for msvc builds.. thats a good thing, considering the changing msvc landscape (the rapid deprecation of vc6, rapid uptake of vc8). The msvc build process is rather daunting for n00bs. having the ability to use the msvc ide project files would be fantastic; and would, i think, attract new people to allegro.

With intrinics being so much easier to understand; we will get more/better quality work done in the area... i dont see to many people jumping at the chance to add ASM code :P


aj.



Kalle Last wrote:

I'm not sure if it is a good idea to use pure ASM. For the most part intrinsics can do (almost?) the same job and they should be portable between gcc, icc and msvc as far as I know. Of course if ASM is needed for executing some specific machine instruction intrinsics wouldn't probably work.

2006/1/12, Elias Pschernig <elias@xxxxxxxxxx <mailto:elias@xxxxxxxxxx>>:

    On Thu, 2006-01-12 at 23:21 +1100, Peter Wang wrote:
    > On 2006-01-11, Chris <chris.kcat@xxxxxxxxxx
    <mailto:chris.kcat@xxxxxxxxxx>> wrote:
    > > On Wednesday 11 January 2006 23:30, Peter Wang wrote:
    > > > Not to pull this too far off track but, at least on Unix,
    the C-only
    > > > builds ought be given different names too.
    > >
    > > Is the C-only version incompatible with the asm version?
    >
    > Yes.  The bank switching routines use different calling
    conversions, but
    > also some internal symbols exist in one version but not the other.
    > For example, when I try to run a binary compiled with an
    asm-Allegro
    > against a C-Allegro, I get this message:
    >
    > ./examples/ex12bit: symbol lookup error: ./examples/ex12bit:
    undefined symbol: _mask_mmx_16
    >

    Maybe it's time to remove the asm version in both branches? I can see
    the following advantages:

    - solves the above incompatibility
    - better performance
    - no more liballeg_unsharable.a
    - simplified windows build process

    Vs. disadvantages:

    - extra work
    - throwing away working ASM code somehow feels bad, even if it's
    outdated..
    - reduced performance on things like intel 386 and 486 (are they still
    in use though, and does Allegro still work on them?)
    - it may be harder introducing new asm in the future (e.g. once no
    more
    mingw is required to create a windows build, it has to stay that way)

    For future asm code, we should try to make it compatible to the C
    functions if that is possible.. I assume, you can somehow specify the
    calling convention for ASM functions as well, and also write ASM PIC
    code? But I'm not very sure about details of both.. i.e. why are they
    problems at all :/

    --
    Elias Pschernig



    -------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc. Do you grep through
    log files
    for problems?  Stop!  Download the new AJAX search engine that makes
    searching your log files as easy as surfing the  web.  DOWNLOAD
    SPLUNK!
    http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
    <http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click>
    --
    https://lists.sourceforge.net/lists/listinfo/alleg-developers




--
Kalle Last





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/