Inline assembler support
Archives Forums/Win32 Discussion/Inline assembler support
| ||
| Can we have inline assembler support? |
| ||
| You can import ASM files/files directly in bmax, Import "Test.a" Extern ;Link to above code- End Extern. |
| ||
| I know about importing asm files, but im want inline assembler :) i dont whant to write full asm sources, but only small parts... |
| ||
| How does the size of the asemmbly file make importing it less useful? |
| ||
| Inline assembler usually allows usage of variables created in the host language. It's very easy and very powerful. Not multi-platform of course. |
| ||
| Not multi-platform of course. there are good examples of languages that are multi platform and support inline assembler ... |
| ||
| Well, there'd be no reason not to use the ?PPC, ?x86, ?Mac, ?Linux or ?Win32 compiler directives. |
| ||
| there are good examples of languages that are multi platform and support inline assembler ... A pedantic point. The moment you use assembler you lose cross platform compatibility. Of course you can re-write chunks of code for different processors but that's not the same thing is it? Currently writing in straight Blitzmax results in code which will compile on each platform supported. Personally I think that's a rather valuable feature. |
| ||
| I just assume that you never used PureBasic otherwise you wouldn't write something quite pointless. BlitzMax isn't "crossplattform" as well from your point of view as the implementation behind the scene is different for each plattform and just 1 set of calls for all plattforms. |
| ||
| BlitzMax compiles to 3 platforms from the same source files. That is the very definition of cross platform. It can do whatever it feels like behind the scenes - it's what I have to write on my side of the screen that matters. |
| ||
| Dreamora. What are you on about? |
| ||
| In some cases inline ASM could be handy. True, you may have to change parts of it depending on the platform using ? tags, but hey, thats the price for speed. |
| ||
| There's no real reason why those against it should be arguing, it's another one of those 'don't like it don't use it' sorta features... |
| ||
| It's not a priority. I've seen that riot fella argue against stuff before though. Tut tut. |
| ||
| Never anything useful. =] |
| ||
| not everyone is going to make multiplatform stuff, so to them inline asm stuff is actually useful. I myself will not make multiplatform stuff, but I will use BlitzMax for all my windows needs. |
| ||
| >not everyone is going to make multiplatform stuff, so to >them inline asm stuff is actually useful. Possibly. I love using inline assembler myself. I stopped using it when I realised that compilers often generate more optimal code than me. |
| ||
| I stopped using it when I realised that compilers often generate more optimal code than me. And this is really the point these days. It's doubtful that anyone here knows assembler well enough to outperform what the compiler spits out already. That's not a knock on the coders here, it's just reality. I can count on one hand the number of places that the Unreal engine uses inline assembly ... and even in those places, if they were thoughtfully rewritten, could probably do without it. |
| ||
| Back in the DOS days, inline ASM had more benefits than just a potential speed increase -- Since hardware was directly accessible under DOS, it would allow you to actually extend the capabilities of your program itself, and add new functionality that could not be accomplished with the built-in commands of many languages. For example: PowerBASIC for DOS only had native support for screenmodes up to 640x480, in 16 colors. Using inline ASM, I was able to interface with VESA video adapters directly, and enable hi-res 256 and true-color screenmodes, among others. Nowadays I think inline ASM is of a much more limited use than back then, since windows 2000/XP/etc no longer allows applications to access hardware directly. Sure, you can 'optimize' certain code by hand-coding it in ASM, but it does take an awful long time to do so, for relatively little gain with todays' efficient compilers. In most (not all, but most) cases, it's simply not worth the time spent on it. |
| ||
| Bmax includes FASM, which, as far as I know, is a generic assembler that is available on multiple platforms. This is the way PureBasic does it: You include the FASM (Flat ASseMbler) source directly in your PB source and, depending on what platform you're running it on, it is compiled by the version of FASM made for your system. Naturally, there are some drawbacks. If you want to use ASM codes that are specific to a particular processor then you will most likely be out of luck. However, I think the advantages to this approach far outweigh the disadvantages and FASM actually does a very very good job of creating its compiled code. That being said, I think really only a very very small percentage of Blitz programmers would ever make use of this feature. It is nice to have there "just in case" you want to write some device drivers or have a very CPU-intensive section of code that you want to speed up, etc. (Or parhaps you want to write an entire OS like this guy: http://www.menuetos.org/ - which fits entirely on a single floppy!) Anyway, the ability is there and could probably be made completely inline (so you can access variables, etc) pretty easily... Russell |
| ||
| struggling to think how I could inline this to make it better.... okay this is a very simple example, but generally the max produces nice compact code... most languages that let you inline with language variables usually output *hideous* code, pushing and popping between each inline "asm" So usually no faster and ofter slower... As for being closer to the hardware so you can extend the language are you really interested in coding for 20 different sound cards... Instead of trying to knock off the odd millisecond a frame look again at your algorithm, sometimes its not the odd millisecond but 10 times that. rem mov ebx,5 mov dword [ebp-4],6 mov edi,7 mov ecx,8 mov edx,9 mov eax,10 mov dword [ebp-8],11 jmp _3 _5: add ebx,1 add dword [ebp-4],1 add edi,1 add ecx,1 add edx,1 add eax,1 add dword [ebp-8],1 mov esi,ebx add esi,dword [ebp-4] add esi,edi add esi,ecx add esi,edx add esi,eax add esi,dword [ebp-8] cmp esi,1 jge _15 jmp _4 _15: _3: cmp ebx,10 jl _5 End Rem a:Int=5 b:Int=6 c:Int=7 d:Int=8 e:Int=9 f:Int=10 ' oh no we've run out of registers!! g:Int=11 While a<10 a:+1 b:+1 c:+1 d:+1 e:+1 f:+1 g:+1 If (a+b+c+d+e+f+g)<1 Then exit Wend |
| ||
| Honestly, I feel that inline asm should be low on Mark's priority list. But the possibility is definately there for someone to do it right now, since we know that FASM is already used by BlitzMax for something.... Also, Chris C, I agree with your points. Slightly OT, but why do I see a lot of people use such nondescriptive label names in their asm code, like '_15' and '_3'? It's been a long time since I dabbled in asm, but I'm sure there's a reason, eh? ;) Russell |
| ||
| Slightly OT, but why do I see a lot of people use such nondescriptive label names in their asm code, like '_15' and '_3'? It's been a long time since I dabbled in asm, but I'm sure there's a reason, eh? ;) They're labels generated by the compiler. |
| ||
| @ John I stopped using it when I realised that compilers often generate more optimal code than me. hehe ;) |
| ||
| I think it's a great feature for using self modifying code to speed up some things vastly. Besides that, I'm sure mark could actually just write a very thin abstraction layer that basically spits out 1 for 1 asm opcodes except for the parts where multi-platforms give ambuiguity. Like...register names. |
| ||
| I personally feel that inline C would be better.. :) |
| ||
| except for the parts where multi-platforms give ambuiguity. Have you really ever compared Intel assembly vs PowerPC assembly? Like...register names. |
| ||
| Have you really ever compared Intel assembly vs PowerPC assembly? Of course I havn't. That would mean I had an informed opinon. People with information don't need opinons. (Barry Zuckerman was my mentor.) |
   |