Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Thief^]

GCC does that exact same optimization with inline assembly... That is why you specify what your input/output is, the constraints on them, and register usage is when you make the inline call. Just so it can optimize it.

I would like to see something specific GCC could optimize from an intrinsic it couldn't from inline assembly. I'm totally open minded to that.

I just looked it up, and GCC does seem to be less braindead than VC++ about inline asm. In VC++ you don't specify inputs, outputs, or trashed registers...
However if you access any memory from GCC's asm, you have to tell it you trash "memory", and it forces the compiler to write all temp registers to ram before the asm block and reload any after the asm block. Not very nice...

[devek]

Lol, _m128 isn't in the c standard. It represents a xmm register and you know it.

Asking for a register and not caring which one you get, doesn't make it C because there are examples of that already existing in assemblers. What was that one assembler atari or someone made that could use infinite registers?

int a is a variable.. it doesn't ever have to touch a register, the compiler can do with it whatever it wants and it certainty isn't specific to the intel platform.

And I showed you how to avoid trashing memory in the example above. I told it I was going to clobber the EAX register.. so the compiler can make a choice. If it can avoid having EAX in use during my code, it can let my code clobber it without any ill effects. If EAX is in use and that can't be avoided, it pushes it to the stack and pops it off after my code. GCC makes that choice. It doesn't have to save the state of all of the registers if I code correctly Since I defined my inputs, if it can arrange for my input to already be in a different register... my inline assembly will use that instead of a variable on the stack. If it sees my output is going to be used soon, it will leave it in EAX or something since I clobbered it anyway.

I've looked at the code output of GCC when using inline, there is nothing wrong with it at all. I'm not against using intrinsics, and I have been using them. I just haven't seen a case where GCC did something better with the intrinsic than my inline.

I have never used MSVC, so I don't know the first thing about it. I do know it doesn't even support inline asm for 64 bit, so I guess if you're using MSVC you totally should use intrinsics only.

[Thief^]

Well no, _m128 isn't C standard. It also doesn't represent a register, you can have pointers to that type and members of that type, and it will store it in ram perfectly sanely.

[devek]

Which is no different than how a high level assembler works.

One last thing:

I showed you how checking for designation uses millions of cycles in memory access..

Despite how long it would take to write, the best possible code would be total assembly but there is nothing you can really do to make checking the dirty bits fast with the given data layout.

A C++ version would have slightly more overhead, but I believe that overhead would be absorbed by the cpu's out of order execution while it is waiting on memory.

A Java version would also have more overhead, but that too should be absorbed by the cpu's out of order execution.

Would you agree, that is is possible.. for Dwarf Fortress specifically, to run the exact same speed in Java, C++, and assembly?

[Thief^]

Assuming a JIT Java runtime, sure (though the startup would be horrendous). For the C++ vs assembler, remember I argued assembly wasn't much faster (if at all) for normal work. Flag checking counts as that, so of course I'd agree.

[ZCM]

When pathfinding to a task(construction, mining, etc.), rather than path to each of the 8 directions, why not path to the tile itself(temporarily marking it as passable, if required) and then stop one tile short?

Also, pathfinding will remain a huge issue for the exact same reason that you propose it isn't: Exactly how many times will it need to retrieve data about the terrain? Reducing the excess sprawl of the pathfinding would reduce cache misses thus, if I understand correctly, leaving more cache for other things.

AFAICT it doesn't path to each of the 8 directions; it picks one of them arbitrarily, and paths to that one. That's why your dwarves sometimes decide to mine a block right next to them but run hundreds of tiles around to get to the other side. Of course, that wastes pathfinding time.... It would probably be faster to use a reversed A* search to path to all eight possible squares simultaneously.

[ZCM]

Which is no different than how a high level assembler works.

As long as you consider C (and by extension C++) to be a high level assembler, sure. I've heard it referred to as such more than once....

So why were you arguing, again?

[devek]

It matters when you are calling specific assembly instructions from your C code and saying it is still a C program. ISO would disagree.

[ZCM]

It matters when you are calling specific assembly instructions from your C code and saying it is still a C program. ISO would disagree.

No, ISO wouldn't disagree:

"A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program."

"A conforming program is one that is acceptable to a conforming implementation."

[devek]

Logic error.

I have a conforming implementation of a C compiler for the iphone. A program that calls assembly instructions directly will not be acceptable to that implementation.

Therefore, a program that calls assembly instructions directly MAY not be acceptable to a conforming implementation.

The standard doesn't say that last line, oops.

[ZCM]

Logic error.

I have a conforming implementation of a C compiler for the iphone. A program that calls assembly instructions directly will not be acceptable to that implementation.

Therefore, a program that calls assembly instructions directly MAY not be acceptable to a conforming implementation.

The standard doesn't say that last line, oops.

A conforming program only needs to be acceptable to one conforming implementation. A program that is acceptable to every conforming implementation is called "strictly conforming".

This is a major difference between C/C++ and, say, Java.

[devek]

Sweet. So based off your reading, I can make extensions to GCC that allows it to compile java source files. (someone did!)

Now I can be an asshole and confuse every discussion by claiming that my program is really a C program, since it can be compiled by a compliant implementation.

C for all!

[Thief^]

LOL

[devek]

I was even thinking, I could add intrinsic java functions to C since inline java might not be optimal

So you could be like...

char []hello = "Hello World!";

_java_System_out_println(hello);

Gcc could be all smart and convert that char to a java.string, reorder it, the possibilities are limitless and it would still totally be c and not c code with java in it.

[Thief^]

Well that specific example would be calling Java from C. The code you have there is still C code (except you misplaced your [] ).

EDIT: But anyway, the point of intrinsics is native compiler support. Java in the compiler wouldn't count unless you were compiling your C to Java bytecode (which I believe has been done), and then it would even make sense to have certain Java functions available as intrinsics.