CakeAlexS
Er guitar dood with all due respect you seem to think you are the only developer here. I own a copy of visual studio too and my degree is in computer science. That doesn't make me a know it all or qualify me to judge what you know or do not know. Nothing I said was incorrect in my last statement. You merely expanded it but again neglected to mention that actually some operations and subroutines (not just registers etc) are specifically optimized for 64 bit code. In a lot of instances some of the assembled code can be far more efficient. 64 bit compilers are different to 32 bit compilers. End of.
Wrong sir!
First, my comment was directed at your statement that "64-bit compilers are different than 32-bit compilers". This implication that 64-bit code is generated with a different compiler than the 32-bit is a patently false statement. Most modern compilers have switches that turn on certain optimizations depending on the mode, but is not separate compilers for the different modes.
Secondly, being a casual or even advanced programmer in Visual Studio does not necessarily equate to intimate knowledge of the CPU's machine language, in which all compiled languages eventually get translated. One of my original classes in computer science (1981) entailed the instructor giving us a cardboard CPU simulator. It had a sliding piece of cardboard for the accumulator, a sliding piece of cardboard for the register and yet another sliding piece of cardboard for the stack. Our task was essentially to "be the one-operations-per-minute CPU" and execute the machine language instructions, in binary I might add. Most of my classmates at the time could not even get past the binary math and the decimal-to-binary conversions let alone understand pushing and popping (EDIT) a stack. One of my first professional projects entailed writing assembly language interfaces between the high-level Informix 4GL (which compiled to 'C', which compiled to assembler, which compiled to machine code) and Allen-Bradley PLCs (ladder-logic) for a Westinghouse Job Costing system we were developing. So when it comes to CPU logic and machine code, I'm quite versed. Not necessarily a know-it-all, but definitely a have-forgotten-more-than-some-will-ever-know. But, I digress.
To further illustrate my point, here's an example for you:
Note: all created with a single version of the GNU C compiler, specifically: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 This is pretty much the compiler being used on 85% of the non-Microsoft platforms and about 98% of non-Microsoft embedded systems.
helloworld.c
#include <stdio.h>
char *main(int argc,char *argv[])
{
printf("Hello World\n");
}
Here's the 23-line i386 (32-bit) Assembler that the C compiler creates:
helloworld_i386.s
.section __TEXT,__text,regular,pure_instructions
.globl _main
.align 4, 0x90
_main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
call L1$pb
L1$pb:
popl %eax
leal L_.str-L1$pb(%eax), %eax
movl %eax, (%esp)
call _puts
addl $8, %esp
popl %ebp
ret
.section __TEXT,__cstring,cstring_literals
L_.str:
.asciz "Hello World"
.subsections_via_symbols
Here's the 69-line x86_64 (64-bit) Assembler source:
helloworld_x86_64.s
.section __TEXT,__text,regular,pure_instructions
.globl _main
.align 4, 0x90
_main:
Leh_func_begin1:
pushq %rbp
Ltmp0:
movq %rsp, %rbp
Ltmp1:
leaq L_.str(%rip), %rdi
popq %rbp
jmp _puts # TAILCALL
Leh_func_end1:
.section __TEXT,__cstring,cstring_literals
L_.str:
.asciz "Hello World"
.section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame0:
Lsection_eh_frame:
Leh_frame_common:
Lset0 = Leh_frame_common_end-Leh_frame_common_begin
.long Lset0
Leh_frame_common_begin:
.long 0
.byte 1
.asciz "zR"
.byte 1
.byte 120
.byte 16
.byte 1
.byte 16
.byte 12
.byte 7
.byte 8
.byte 144
.byte 1
.align 3
Leh_frame_common_end:
.globl _main.eh
_main.eh:
Lset1 = Leh_frame_end1-Leh_frame_begin1
.long Lset1
Leh_frame_begin1:
Lset2 = Leh_frame_begin1-Leh_frame_common
.long Lset2
Ltmp2:
.quad Leh_func_begin1-Ltmp2
Lset3 = Leh_func_end1-Leh_func_begin1
.quad Lset3
.byte 0
.byte 4
Lset4 = Ltmp0-Leh_func_begin1
.long Lset4
.byte 14
.byte 16
.byte 134
.byte 2
.byte 4
Lset5 = Ltmp1-Ltmp0
.long Lset5
.byte 13
.byte 6
.align 3
Leh_frame_end1:
.subsections_via_symbols
Perhaps you could share how the 69-line 64-bit assembler code is more optimized than the 23-line 32-bit code, because I certainly don't see it. The binary versions had a difference of 44 bytes, with the 64-bit version being the larger at 8688 bytes.
Upon runtime, the only performance gains I was able to see were in the the runtime dynamic linker able to load the code 0.012 seconds faster on the x86_64 bit.
I'm sure that a more complex program would benefit, however, that benefit is overshadowed by the instability of using another program in every fx-chain (bit-bridge) for 90% of my plugins(fx which are mostly still 32-bit) as opposed to using jbridge for 10% of my plugins(soft-synths, which btw can easily be frozen and/or converted to audio eliminating the necessity for having the soft-synth active throughout the entire mixing process. This is for my system. If you're happy with the status-quo, more power to ya.
And btw, you could have made your point without the personal attacks. I don't think I'm the only programmer here and only called you on your false statement which you made in such an authoritative posture.
Best,
EDIT: for anyone interested, here is the wikipedia page for the CARDIAC (
http://en.wikipedia.org/w...ve_Aid_to_Computation) cardboard computer which actually has 4 slides. I forgot about the memory cells.