Porting Voxlap

[mach1ne]

Never thought I would actually see it running in Linux, even only for a few seconds :P

[Sonarpulse]

Seeing that screenshot makes me way too happy :D mind if I edit it in to the first post?

[mach1ne]

Seeing that screenshot makes me way too happy :D mind if I edit it in to the first post?

Go right ahead

[VladVP]

Never thought I would actually see it running in Linux, even only for a few seconds :P

Thats freaking awesome! I might test it on my virtual machine... if something can emulate someone's grandma's rig, it is a virtual machine on windows.

[VladVP]

Here's the thing, the very new "%c" tells gcc to deference [name] value. The parenthesis are at&t syntax way of dereferencing the assembly: gcc just passes it to the assembler verbatim. If it weren't for the fact that I knew because of the "p" constraint that the value given (the address of a global variable) would have to be resolved to a (link-time) constant and thus a number with new dollar prefix, I would probably end up with two sets of parenthesis verbatim.

important to note: when one uses a constraint such as "m", the value is referenced automatically, and then dereferenced automatically so you need neither %c, nor & in the C expression. With "r" it likewise substitutes the value for the register name, which is also sort of like referencing except register names are "dereferenced" back to their contents automatically. With "p" it DOESN'T automatically reference the value, which is why I have to do that in the C expression.

Ahh, so %c is a GCC thing for [name]s? Then I think I understand.

Here's the thing, I don't really know whether it's faster to hack some C that works with both compilers and then fix the gcc assembly, or vice versa, which why I see no_asm and conservative as the first step, and do a hell of a lot of rebasing in git. Certainly working on either branch will help the other one, so do whatever you think is best.

On a somewhat related, when I emailed the gcc help thread, they suggested that I make a test_main, so to speak. So far I have just done been doing static code comparisons, but especially if we are going to try to get conservative working first, some dynamic testing would go along way. It will be a pain to run the MSVC and build up tables of values, but if we buckle down and do it I think we'll be glad we did.

I think I'll work on conservative until we can proove that simply converting the assembly, and fixing some of the C wont help.
And yes, a bit blackbox testing on all of the functions in voxlib.txt probably wont hurt anyone.

Hmm... looks complicated... I'll try taking a look at it tomorrow...

Great. GreaseMonkey said that it has do with unpacking vxls, which matches what little I can gleam from it. Some of It I can easily turn into a do-while loop, and there are a couple other things to make it more readable, but I left it as is for now so it can be compared side by side to the assembly (and hopefully the disassembly can be too.)

Oh, I though you needed help with fixing the syntax... but anyway, I made a flowchart of your C code here:https://www.dropbox.com/s/s5hos5yyqpaw3 ... ucture.png, and then produced some new C code here: https://pastee.org/myue7.
It does indeed need some optimization, and I doubt it will work; but it should be a step in the right direction.

[Sonarpulse]

Awesome! That flowchart especially looks crazy complex. Thanks so much Vlad.

[VladVP]

Awesome! That flowchart especially looks crazy complex. Thanks so much Vlad.

No problem
And if you've had more experience with flowcharts, you'll know that these kind of big bulky flowcharts are actually fairly common (depending on purposes of course). For example I only used exactly 40 elements in this chart, while the "regular" amount of elements can go as high as up to 60 elements... especially flowcharts for software algorithms.
But to be honest, it actually seems this complex because I decided to start move the individual elements around to get more workspace, and it may thus seem a bit unstructured. xD

[Sonarpulse]

I might have mentioned it before, but doing gcc with any optimization level gives assembly that's way too short, and doesn't even mention xbsceil. Perhaps with your knowledge of flowcharts you can figure out what the hell is going on. If we can figure out why gcc thinks there's some dead code we can probably solve the problem with my C and then apply your elegant rewrite.

Here's what I get with "gcc -S temp.c -o- -O3"

Code: Select all

	.file	"temp.c"
	.text
	.p2align 4,,15
	.globl	expandbit256
	.type	expandbit256, @function
expandbit256:
.LFB0:
	.cfi_startproc
	movl	4(%esp), %ecx
	movl	8(%esp), %eax
	cmpb	$32, 1(%ecx)
	jne	.L7
.L2:
	movl	xbsflor, %edx
	cmpb	$0, (%ecx)
	movl	128(%edx), %edx
	je	.L10
.L3:
	.p2align 4,,7
	.p2align 3
.L8:
	movl	%edx, (%eax)
	addl	$4, %eax
	movl	$-1, %edx
	jmp	.L8
.L7:
	movl	$0, (%eax)
	addl	$4, %eax
	movl	$0, (%eax)
	addl	$4, %eax
	jmp	.L7
.L10:
	ret
	.cfi_endproc
.LFE0:
	.size	expandbit256, .-expandbit256
	.ident	"GCC: (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2"
	.section	.note.GNU-stack,"",@progbits

Edit: a clue! from http://stackoverflow.com/a/301285 I learn that expand bit is using signed comparisons. Therefore I surmise that I should change all these uint32_t to int32_t. Hopefully that will help.

[Sonarpulse]

Ok yeah that helped a lot. After I changed everything to do with eax and ecx (since they were used with the jumps) and everything to do with them to be signed, I got the map to load, but with no shading. Then I realized movz meant treat as unsigned integer, so i changed lines like this

Code: Select all

eax = (int32_t)((int8_t*)s)[3];

back to this

Code: Select all

eax = (uint32_t)((uint8_t*)s)[3];

But now the map doesn't even load again.

to recap, the "paradox" is that jump use signed conditions, but eax (used for jumps conditions) is given an unsigned value with movzx.

[Sonarpulse]

It works! The last bit of inline assembly in voxlap5.cpp is now gone. The stuff in regards to the movz was more or less correct, but my tiling window manger was hiding the window so I thought nothing was loading. *facepalm*

[VladVP]

Sorry, I was sleeping (Where exactly do you live? You seem to go online when I go to bed (22:00/10PM), and start going offline around when I wake up and go to school. (7:00-8:00/7AM-8AM) xD)
But that's pretty cool! Have you commited the changes on GitHub? I'd love to take a look at your fixes
So... is this the last .c(pp) file before v5.asm, or are there still other issues?

[Sonarpulse]

haha, well there is a few things in sdlmain, and it's still buggy so I didn't do the C all right. The barebones to get it to compile are on github, but I'm still "un-spagetti-ing" it. That's where your chart comes in handy!

OK, yeah I basically did what you did, except I have an initial jump and then a while loop. I dunno what's better.

[VladVP]

haha, well there is a few things in sdlmain, and it's still buggy so I didn't do the C all right. The barebones to get it to compile are on github, but I'm still "un-spagetti-ing" it. That's where your chart comes in handy!

Yes... I have been considering making a map of the structure of Voxlap; i.e. what functions and subroutines use what other functions...
I actually think I'll attempt that... It would be VERY useful for the blacbox testing that I'm planning to to do on all the functions in voxlib.txt.

OK, yeah I basically did what you did, except I have an initial jump and then a while loop. I dunno what's better.

Yes... I'm glad you've made the while loops, but... well... I would say that all those labels aren't really preferable...
Oh well, if I was you, I'd replace the labels with two loops, like in my flowhchart... But no matter what, I wouldn't really call it a "beautiful" piece of code in it's current state.

[Cajun Style]

Yes... I have been considering making a map of the structure of Voxlap; i.e. what functions and subroutines use what other functions...

Any chance I could help? I'm trying to assign proper types to all the longs, so I'm browsing a lot of code too.
SonarPulse, please consider not changing commits you've already pushed. I'm not sure how many commits you've cut out, but I had to rewind 40 and while rebasing solve 6 "issues" (they were silly). If you think it's more clean to tidy up and compress some commits, please do that on a separate branch. Otherwise I don't really mind a big history.
I'm having some weird issue building now. Linker can't find SDL functions...

Code: Select all

g++ -o binaries/simple.exe  -lmingw32 -lSDLmain -lSDL -mwindows -ggdb -Wall -Wextra -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable binaries/simple.obj binaries/voxlap5.obj binaries/v5.obj binaries/kplib.obj binaries/sdlmain1.obj

[Sonarpulse]

Yes... I have been considering making a map of the structure of Voxlap; i.e. what functions and subroutines use what other functions...
I actually think I'll attempt that... It would be VERY useful for the blacbox testing that I'm planning to to do on all the functions in voxlib.txt.

Yes, I think all three of us should do this. I was thinking get the function documentation and stick it in voxlap5.cpp for doxygen, which I already used in simple.cpp. Then perhaps we can document the static/inline functions too the same way (hopefully doxygen knows what to do for that). I so far have barely even looked at that documentation, which is probably a huge mistake.

OK, yeah I basically did what you did, except I have an initial jump and then a while loop. I dunno what's better.

Yes... I'm glad you've made the while loops, but... well... I would say that all those labels aren't really preferable...
Oh well, if I was you, I'd replace the labels with two loops, like in my flowhchart... But no matter what, I wouldn't really call it a "beautiful" piece of code in it's current state. [/quote]

Eh, I don't think it's as bad as you think. Maybe I hadn't pushed when I wrote the original post, but the only label now is in2it, everything else is done with loops.

Cajun:

before I didn't redo history too much, but then I ended up cherry-picking TONS of stuff between the two branches, and it became hard keeping everything up to date with commits that applied to both. I'll gladly stop destructively updating conservative, but I'll still need to rebase no_asm. Also, try "git merge -m [branch]", which tells it to merge each revision for the rebase and fix some basic errors in the process.

And good work with the types. I think if first we just replace everything with fixed with types, and signed and unsigned as nessisary, and then go back to figure out which uint32_tS should really be uptr_tS. Also, I left you a note in github but in case you didn't see it, the compiler is instructed to treat all char's as unsigned.

As to your SDL link error, first make sure you are running make from MSYS (MinGW Shell) and not CMD. If you are doing that, Msys with it's virtual unix file system makes putting things in "/lib" and "/include" a bit difficult. my SDL headers are in

Code: Select all

C:\MinGW\include\SDL\

my SDL libs are in

Code: Select all

C:\MinGW\msys\1.0\lib\