|
This thread is locked; no one can reply to it. |
1
2
|
Request for C version of asmlock.s |
Troels K
Member #4,252
January 2004
|
Hi, I've created a MSVC project for Allegro, with makefiles isn't everybody's cup of tea. /Troels |
Oscar Giner
Member #2,207
April 2002
|
that zip only contains the MSVC project and workspace and a file contrib/initguid.c -- |
Troels K
Member #4,252
January 2004
|
The rest is here: |
Evert
Member #794
November 2000
|
If you build Allegro using only C (ie, ALLEGRO_USE_C), then you shouldn't need a C version of any assembler file. What do you need a C version of asmlock.s for? Why doesn't it work with ALLEGRO_USE_C? On a side note, this was discussed a long time ago and there was some talk of trying to get the C only version of teh library to compiel with MSVC. I'm glad someone is now looking into that. |
Troels K
Member #4,252
January 2004
|
>If you build Allegro using only C (ie, ALLEGRO_USE_C), >What do you need a C version of asmlock.s for? Why doesn't it work with ALLEGRO_USE_C? allegro.lib(wgdi.obj) : error LNK2001: unresolved external symbol _gfx_gdi_unwrite_bank >C only version of the library is considerably slower... >trying to get the C only version of teh library to compiel with MSVC. /Troels |
Evert
Member #794
November 2000
|
Quote: This seems to be almost true.
No, it is completely true. Allegro runs on Apples and I've run it myself on Sun computers. Quote: While developing and debugging - using the IDEs integrated debugger - it's good to have only C code to singlestep into. Especially when using a code library new to you. When deploying, you can switch to using the official dll (which have no debug information inside). Unless you're developing Allegro (in which case MSVC alone is not going to suit your purposes) you shouldn't need to single step into Allegro code. In fact, you probably don't want to. |
Troels K
Member #4,252
January 2004
|
>No, it is completely true. Allegro [C only version] runs on Apples...non-Windows ports >If noone can confirm or check this (I'm not in Windows, so I can't try it), >Unless you're developing Allegro (in which case MSVC alone is not going to suit your purposes)... >...you shouldn't need to single step into Allegro code. In fact, you probably don't want to. >>While developing and debugging - using the IDEs integrated debugger |
Evert
Member #794
November 2000
|
Quote: Do you really advocate using this library as a black box?!
For the purpose of programming and debugging your own game or application, yes. I certainly don't want to step through an Allegro function when debugging my own code. Quote: Linux users might have a thing or two to say on black boxes. I am a Linux/UNIX user. Quote: A library that compiles right out of the box makes a very favourable first impression.
Sure. But Allegro does compile out of the box and always has - just not with MSVC, but that's because it wasn't originally designed for that particular compiler. |
Troels K
Member #4,252
January 2004
|
>I certainly don't want to step through an Allegro function when debugging my own code. >But Allegro does compile out of the box and always has - just not with MSVC |
Evert
Member #794
November 2000
|
Quote: If one happens to be uncertain about the meaning/interpretation of some parameter you're passing to some function, you can either grep for the function - or debug into it. I think the manual would be the place to look, personally. Stepping into a function just to find out what some of the parameters do seems to me a strange way to go about this. Quote: ...which is very popular, to put it mildly.
Which is why there is an end-user package for MSVC. Anyway, I posted the question on the mailing list, pointing to this thread. Depending on how much work it is to rewrite the Windows drivers in C, someone may or may not want to work on this. |
Troels K
Member #4,252
January 2004
|
It's not like I want to have the last word or anything. But! >>If one happens to be uncertain about the meaning/interpretation of some parameter >The average new user won't be interested in compiling his own library >I posted the question on the mailing list, pointing to this thread. >how much work it is to rewrite the Windows drivers in C, |
Evert
Member #794
November 2000
|
Quote: Documentation and code constantly gets out of sync, that's the way it goes in an
Have you looked at Allegro's documentation? It's rather thorough and it is something that is very closely monitored whenever a change is made or a feature is added. Quote: The documentation might say sure, yes, everything's good and safe, and that might satisfy the trustful programmer. To other programmers, seeing is believing... In other words, you don't trust the docs? Quote: Apparantly all that is needed for a clean MSVC compilation/linking of Allegro is a C version of src\win\asmlock.s. I'm sorry I'm not the one to do it...
Nor me obviously. And as long as noone with the ability to do that actually does it, it's not going to happen. Eric, in reply to my e-mail said said: > It seems that Allegro still needs to build .s files on Windows, even if No, you're right. > It is no big deal for me personally, but it seems to me inconsistent. Sort of. The docs say "Allows you to build the library using C drawing code > The main benefit would probably be insignificant - it would be possible to Yes, and the C-only DLL would be incompatible with the regular DLL because of simplified asm calling conventions for bitmaps. > On the other hand, it may be easier for newbies who insist on compiling the There is a trickier dependency on GCC: the makefiles use very long command (my emphasis) So I guess a true MSVC-only port isn't really feasable with just C code, as I'd hoped it might be. |
Troels K
Member #4,252
January 2004
|
>Yes, and the C-only DLL would be incompatible with the regular DLL because of >simplified asm calling conventions for bitmaps. ALLEG41.DLL and say ALLEG50.DLL needn't have identical interfaces. >the makefiles use very long command lines that regular Win32 apps can't grok The MSVC scenario is completely without makefiles. Apparantly all that is needed for a clean MSVC compilation/linking of Allegro is a C version of src/win/asmlock.s. |
Evert
Member #794
November 2000
|
Quote: ALLEG41.DLL and say ALLEG50.DLL needn't have identical interfaces. We're not talking about different versions of Allegro here, we're talking about the same version and hence (in principle) the same DLL, but compiled differently, resulting in incompatibilities. That is bad, because a program expecting the C-version DLL will die on the asm version and vice versa. Either the DLL would have to be named differently, or the MSVC C only library should be static link only. |
Troels K
Member #4,252
January 2004
|
I'm proposing to change 'simplified asm calling conventions' to __cdecl or Pascal, projectwide, in upcoming versions. |
Fallout2man
Member #4,279
January 2004
|
I too would like to have an MSVC project file (DSP/DSW or VCPROJ/SLN) for building the library. The main reason I want to do this is so I can use the MSVC's options to easily specify what optimizations and such I want run to compile the DLL. I'm not entirely sure what all was said, but what exactly is needed to make a project? I tried myself but kept getting compile errors about non-constant initializers and such. It seems just a bit inconsistent to claim MSVC support yet require additional software to compile it. Nothing against the MinGW implementation of the GCC, it's good and all, but frankly don't hold a candle to the MSVC in terms of making fast and optimized code. |
Evert
Member #794
November 2000
|
Quote: I'm not entirely sure what all was said, but what exactly is needed to make a project? I tried myself but kept getting compile errors about non-constant initializers and such. An assembler that can assemble AT&T style assembler files, which MSVC's cannot. Quote: It seems just a bit inconsistent to claim MSVC support yet require additional software to compile it. Allegro is a cross-platform and cross-compiler library. Since the default Windows toolset is very limited and the MSVC one is mostly incompatible with others, that kind of thing is more or less inevitable anyway. Quote: Nothing against the MinGW implementation of the GCC, it's good and all, but frankly don't hold a candle to the MSVC in terms of making fast and optimized code. The MSVC version uses the commandline version of MSVC to compile C code and MinGW (or DJGPP) to handle the hand-optimized assmebly. There is noone who says MSVC support could not be improved, but it will require a rewrite of all hand-written assembly code in Allegro to do it properly. And unless someone is willing to do that, theentrire discussion is rather pointless. |
Fallout2man
Member #4,279
January 2004
|
The problem with the command line MSVC is I can't reinstall it and my current MSVC directory has spaces in it. This is why I hoped for a project file of some kind, as the only other option would be someone smart adding support for spaces in names to the windows ports of the GNU tools (which is something that also would be very nice). I could always just take a pre-built DLL but as I said I wanted to get a fully optimized MSVC version with compile flags I intended, not something someone else made. Just a bit stringent on that, heh. So as you can see I'm dependent entirely on another way to get allegro to compile on my box. Thanks for explaining the assembly issue. |
Troels K
Member #4,252
January 2004
|
>MSVC support...will require a rewrite of all hand-written assembly code in Allegro |
Evert
Member #794
November 2000
|
Quote: Still, the minimum requirement for compiling Allegro using MSVC seems to be a C version of only the file asmlock.s Resulting in a slower version because you can't use the hand-optimized assembler. That means that you'd need to prevent people from distributing the C only DLL, even if it were binary compatible with the optimized one, or only allow it to build a static link library. Again, I think it'd be a neat idea and a step closer to native MSVC support, but it is not on the same level asa full native port. |
Fallout2man
Member #4,279
January 2004
|
I tried simply renaming the .s files to .C in the MSVC then adding __asm { at the start of assembly code, closing with } at the end. Yet for some strange reason using either _asm or __asm on these files generates a syntax error. Here's a snippet from the build log Quote: ispr8.c Strangely it always says __asm even if I use _asm in the code. Any reason why exactly this seems to occur and these assembly files can't simply use the inline assembler? I also remember there being an example on the MSDN about how to use Assembly files in tandem with C files in a project, probably will need to look that up. One other note: With how highly optimized (current) MSVC code is, as well as the fact it can be set to use specific instructions such as SSE or MMX, why should speed be such an issue, it might even be faster then the hand-made code because it can take advantage of more hardware capabilities across the board, and can also be built to use SSE2. |
Evert
Member #794
November 2000
|
Quote: I tried simply renaming the .s files to .C in the MSVC then adding __asm { at the start of assembly code, closing with } at the end. Yet for some strange reason using either _asm or __asm on these files generates a syntax error.
Don't bother. Allegro's assembler code is written in AT&T syntax. MSVC uses Intel syntax. If either were different, then there'd be no problem and MSVC could compile Allegro on its own just fine. Quote: With how highly optimized (current) MSVC code is, as well as the fact it can be set to use specific instructions such as SSE or MMX, why should speed be such an issue, it might even be faster then the hand-made code because it can take advantage of more hardware capabilities across the board, and can also be built to use SSE2. I think Allegro uses SSE2 if available already. It certainly uses MMX and SSE. Don't underestimate the ability of good programmers (ie, Bob) to optimize assember code - no compiler is capable of the level of optimization that a human can do. |
Fallout2man
Member #4,279
January 2004
|
Not necessarily, not saying that's true in this case but eventually computers are going to pretty much do everything better then we can :p and where can I find something that'd list the differences between AT&T and Intel syntax? I'm no assembly coder but if it's just syntax issues I imagine that with enough time I could at least convert asmlock.s and then maybe try the other files later. |
Evert
Member #794
November 2000
|
Quote: eventually computers are going to pretty much do everything better then we can Dream on Quote: where can I find something that'd list the differences between AT&T and Intel syntax? A quick google turned up this: [url http://www.astrolox.com/?text=attintel]; you may be able to find more. |
Fallout2man
Member #4,279
January 2004
|
It's true, they already have computers that can process faster then the human brain. Once we make the right algorithms they'll do everything better, it's just making those algorithms will take a very, very long time. Anyway, just finished my first try at porting asmlock.s to intel syntax, remember I know nothing of how to truly do assembly programming, just used http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-assembler/i386-syntax.html as a reference and went from there.
Edit: How the hell do you make a link and specify a name for it other then the URL? it's really annoying having it showthe long URL when I wanted to add a simple this as the name. |
|
1
2
|