NASM - The Netwide Assembler
NASM Forum => Other Discussion => Topic started by: coldev on March 04, 2014, 05:32:50 AM
-
is possible convert this ASM to C code?
3d engine OPENSOURCE, code in DJGPP AND NASM
http://www.ii.uib.no/~alexey/vpe/index.html
thanks.. is to port in android,,,,
credits will be included..
attached 3 asm files
https://www.mediafire.com/?zqpk5b8uw3babe6
-
is possible convert this ASM to C code?
.it is possiblE
const char * text = "ASM" // and here you go. .donE
;D
-
please help... only 3 tiny files in 486 assembly to port in C++
https://www.mediafire.com/?zqpk5b8uw3babe6
thanks..
-
Answer 1:
please help... only 3 tiny files in 486 assembly to port in C++
Why? So you can get money from employer for finished job? :D
Answer 2:
Well i think you have unrealistic expectations, that someone, from the clear sky, will go and do something for you.
This is how it works - perfectly: employ somebody, who can, to do that for you.
That's why there are special web sites for this, that is: Where Employer meet's Employee.
Plan A: "Can't afford to employ somebody".
Solution: "- Then try to bribe somebody with cola, beer, pizza, other goods". :D
-
Well i think you have unrealistic expectations, that someone, from the clear sky, will go and do something for you.
That statement sums up my point of view regarding the OP's request as well.
-
alexey not update your project ...
http://www.ii.uib.no/~alexey/vpe/index.html
our work is opensource and non profit ...
our group dedicated your free time to port projects in other platforms...
please help us and credits be included ...
check some projects from Team :
https://code.google.com/u/100998669591384944124/
please help... only 3 tiny files in 486 assembly to port in C++
https://www.mediafire.com/?zqpk5b8uw3babe6
-
How would it be if the Nasm Development Team said, "Why should we write an assembler for you? Write your own!"? Just sayin'...
I've taken a quick look at the code, and it strikes me as "weird". We've got a big unrolled loop, and jump into the middle of it - not by jumping, but by precalculating the address and pushing it, and later doing a "ret" (messing up branch prediction in some CPUs?). I have no idea how you'd express that in C(++). I'd be willing to help out another open source project, but I don't think I have the skills.
Don't give up, Coldev, just because you got an initial bad reaction here. Now that you've made it clear that this is for an open source project and not "so my employer will pay me" (you did say that!) you might find people more willing to help. Maybe if you made it a "challenge"..
I'll bet you can't convert this to C! :)
Best,
Frank
-
Don't give up, Coldev, just because you got an initial bad reaction here. Now that you've made it clear that this is for an open source project and not "so my employer will pay me" (you did say that!) you might find people more willing to help. Maybe if you made it a "challenge"..
Yes, the "initial bad reaction" was indeed a response that assumed the OP wanted either employer-work or home-work done gratis.
Since it is for an open source project I looked over the given website to validate the claims and subsequently did not lock the topic but simply moved it here for possible future responses.
-
I've taken a quick look at the code, and it strikes me as "weird". We've got a big unrolled loop, and jump into the middle of it - not by jumping, but by precalculating the address and pushing it, and later doing a "ret" (messing up branch prediction in some CPUs?). I have no idea how you'd express that in C(++). I'd be willing to help out another open source project, but I don't think I have the skills.
I took a look at the code a few days ago when the OP started this thread. The reason I didn't respond was mainly due to the "wierd"ness of the code as you mention. In fact, one of the first things I did was glance at the OLoop macro which "unrolls" the following code:
mov bl, [esi]
mov bl, [ebx]
mov [edi], bl
add edi, ebp
add eax, ecx
adc esi, edx
After seeing that, I figured I wasn't up to the task of trying to figure out why the original developer was doing that. I can't imagine that "unrolling" OLoop was going to do much for optimization. :P
Don't give up, Coldev, just because you got an initial bad reaction here. Now that you've made it clear that this is for an open source project and not "so my employer will pay me" (you did say that!) you might find people more willing to help. Maybe if you made it a "challenge"..
I'll bet you can't convert this to C! :)
I disagree... give up Coldev. Not because it's impossible, but mostly because of your goal itself. You want this for the purpose of developing android apps.. Great! Find a copy of the Allegro port for the VPE, then get a copy of the Allegro wrapper for SDL, then use the SDL version for android. That should take care of any hardware specific components of VPE. For the remaining fluff that Frank and make mention of above, you should get someone more familiar with the project to refactor/retarget the code into ARM assembly language rather than 80x86. I'm not an ARM programmer but I can't imagine there would be too much difficulty for someone who knows both dialects to translate between the two (much easier than changing between languages).
-
const char * text = "ASM" // and here you go. .donE
But you have to convert the ASM code to the matching syntax ;D ;D