First, let me say that I am extremely enthused about D. I
did research on it last year for a project and absolutely fell in
love with it. But praise should go in another thread...
My question comes down to:
"Does dmd pack non-array primative variables in memory such that
they are touching, or
We have size_t defined as uint on 32bit and ulong on 64bit.
ptrdiff_t for int/long.
I don't know how dmd handles it, although you do have the
ability to align variables.
You may want to consider gdc or ldc more than dmd as they have
better optimization.
Sorry for the delayed response - distrac
Keep in mind that RAM access is slow compared to how fast CPUs
run. It can be beneficial to have "slower" data types if they
allow more data to fit into the CPU cache.
Abosolutely fantastic point, Marco!
Except if everything still fits in cache as "fast" types, it'd be
worth having faster type
On Friday, 3 January 2014 at 05:25:49 UTC, Casper Færgemand wrote:
On Wednesday, 1 January 2014 at 04:17:30 UTC, Jake Thomas wrote:
snip
Are you looking for something like int_fast32_t and the likes
from Boost? If you don't care terribly much for when your
numbers overflow, then as o
According to this
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff561499(v=vs.85).aspx)
32-bit registers are automatically zero extended on x64
architecture while 16-bit and 8-bit registers are not.
"Operations that output to a 32-bit subregister are automatically
zero-extended
On Sunday, 5 January 2014 at 08:23:45 UTC, TheFlyingFiddle wrote:
On Sunday, 5 January 2014 at 06:31:38 UTC, Jake Thomas wrote:
And got 86,421 lines of assembly!! I expected a load
instruction to load whatever was at loadMe's location into r0
(the return register) and not much else. May
Ok, I figured out how to use obj2asm. The trick is to cd to the
directory holding the file you wish to dissassemble and _not_
specify the whole path, or else it throws a confusing "Fatal
error: unrecognized flag" error.
I ran:
obj2asm intLoadTest.o intLoadTest.d > intLoadTest.s
and got this:
Oh, and that was made from:
int main()
{
int loadMe = 10;
return loadMe;
}
Well since you could potentially create classes through
Object.factory at runtime the code for unused classes will be
compiled into the binary anyways this is even if you never use
Object.factory directly in the code. I am not 100% sure but i
think the main problem is ModuleInfo that keeps ever
