Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-

Fucking MingW

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-11-04 9:11

#include <stdio.h>

int main() {
 printf("Hello world!\n");
 return 0;
}


Default MingW compilation+link size: 47KB
Best MingW compilation+link size: 8KB

Default MSVC compilation+link size: 40KB
Best MSVC compilation+link size: 1KB

After postprocessing:
MingW (using MS's linker and libs): 1594 bytes
MSVC: 624 bytes

What the fuck? Am I missing something here?

MingW optimised command line (compile only):
gcc -nostdlib -Os -c -s -o hello.obj hello.c -Wl,--gc-sections,--section-alignment,4096,--file-alignment,512

MingW link command line:
link hello.obj msvcrtlib mainstub.obj /align:4096 /filealign:512 /entry:main /merge:.rdata=.text /merge:.eh_fram=.text /merge:.text.st=.text /section:.text,EWR /stub:mzstub64.exe

mainstub.obj is a dummy __main because libming32.a which is supposed to contain it also contains __CTOR_LIST_ and some other C++ shit. I'm compiling a C program, with gcc, and they force you to link with a bunch of C++ shit? Are you kidding me?

(Why won't it merge the bloody .eh_fram and .text.st sections?!?! Maybe this is a bug of MS's linker since it merges fine with its own compiler output, but the compiler shouldn't be generating .eh_fram and .text.st anyway!)

Executables for your inspecting:
MingW: http://pastebin.com/vZn5WtMz
MSVC: http://pastebin.com/AV63Hr5x

Therefore, I challenge anyone to come up with a smaller Hello World using MingW, and post the commands you used to do it.

Name: Anonymous 2012-11-04 9:18

Name: Anonymous 2012-11-04 9:42

What's a few hundre bytes between friends?

Name: Anonymous 2012-11-04 11:30

>>2
fuck off fagshit

Name: Anonymous 2012-11-04 14:01

I tried Googling about on your behalf, but what I found is totally unhelpful:

http://www.mingw.org/wiki/Large_executables

>>1,3
I suppose the real question to ask is, why do you care? If you are really that concerned about performance, I think you are going to be stuck using msvc or icc on Windows anyway.

Yeah, I know both of those suck for various other reasons, but at least you can keep mingw around for your build scripts instead of using .vcproj or whatever terrible thing Microsoft expects you to use.

Name: Anonymous 2012-11-04 15:15

>>1

comparing anything based on ``hello world''

The extra few kilobytes will be irrelevant once you write a real program.

>>5

Doesn't Visual Studio come with nmake, which is a POSIX-compliant make?

Name: Anonymous 2012-11-04 15:24

you should feel bad for using winshit

Name: Anonymous 2012-11-04 15:29

>>5
It does, and POSIX make will get the job done fine if you are building a trivially small project. For bigger stuff, your options are: gmake (in MinGW, decently fast and very powerful), autoconf + automake (gag me, also slow), or CMake (not really make, but really fast).

Name: >>8 2012-11-04 15:37

>>5
Oh, and in case it's not clear why POSIX make isn't a real answer for big projects:

[1] POSIX make has next to no support for generic rules. Pattern rules? Haha you wish, use .SUFFIXES.

[2] It is also totally incapable of supporting dependency generation on its own. There's no include, at all, so you need to write your own shitty makedep or whatever. If your compiler isn't gcc, this will be just loads of fun.

Name: Anonymous 2012-11-04 15:51

I don't know why people say FrozenVoid left when he's clearly been here all along.

Name: Anonymous 2012-11-04 16:09

>>9
Regarding [1]: I recently wrote a Makefile to track an arbitrary number of Metapost diagrams from one .mp file to put into a latex document, without giving it each possible .1, .2, .3... file individually.
The solution is trivial, and that's to give it a dummy target file that's touched after successful compilations.

I also once wrote a generic Makefile that allows recursion deep into file heirarchies, without recursive make calls, without name clashes from identical filenames in different folders, with a simple OBJECTS= and SUBDIRS= system for each subfolder's module.mak, and with pretty output.

I don't see why I should use a different build system when this one suits me perfectly fine and is very portable.

Name: Anonymous 2012-11-04 16:15

>>9

There's no include

Thankfully, they added this in Posix 2008:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_76_13_02

Name: Anonymous 2012-11-04 16:22

intel-loving kike

Name: Anonymous 2012-11-04 17:02

>>11

How did you do it? Did you generate absolute paths down from the root directory?

Name: Anonymous 2012-11-04 17:30

>>14
I'm not entirely sure of the specifics any more, but here's the skeleton for every directory's module.mk:

DIRS    :=
OBJS    :=

### Do not edit below this line!
PWD    := $(dir $(lastword $(MAKEFILE_LIST)))
ALLOBJS    := $(ALLOBJS) $(addprefix $(PWD), $(OBJS))
ifneq ($(DIRS),)
include $(addprefix $(PWD)/, $(addsuffix /module.mk, $(DIRS)))
endif

DIRS being all subdirectories, and OBJS being source/object file names with extensions stripped.
The root Makefile includes
include ./module.mk
OBJECTS := $(addsuffix .o, $(ALLOBJS))


I guess I was slightly misleading when I said "without name clashes from identical filenames in different folders", because apparently all .o files get put alongside all .c files. But that's easy enough to change, I just didn't need to at the time.

Name: Anonymous 2012-11-04 17:49

>>11
Works great until you delete one of the .n files.

>>12
Neat, didn't know that. I wonder if nmake supports using it in POSIX mode...

>>14
That's pretty much the only way to do it.

>>15
$(dir $(lastword $(MAKEFILE_LIST)))
This is textbook GNU make.  I thought you had done everything in >>11 using only POSIX make - that would be really impressive.

Name: >>16 2012-11-04 17:56

>>15
Everything below

### Do not edit below this line!

can be changed to a regular macro and hoisted up into the main makefile. All you really need to have is an include_dir macro that you can eval to include all the module files.

Name: Anonymous 2012-11-04 18:44

>>16,17
Ah. I had a feeling it wasn't unsurpassably incredible. Cheers for the tips.

Name: Anonymous 2012-11-04 19:16

This entire fucking thread is worthless because all of these compilers are trash.

TCC absolutely destroys all of its' competition in terms of output size, compilation time, and pretty much anything else you can think of. It also supports C scripting just because it's that awesome.

TCC manages to be this awesome and take up how much space? The TCC executable, including C preprocessor, C compiler, assembler and linker is 100 KB. That's right. You can fit this shit on your floppy.

Name: Anonymous 2012-11-04 19:26

>>19
TCC also doesn't support even a tenth of what all the other big name compilers do. I'm sure it's nice if you don't need something ``exotic'' like -ffunction-sections, but if you do...

Also,
http://bellard.org/tcc/
I am no longer working on TCC. Check the mailing list to get up to date information.

Name: Anonymous 2012-11-04 19:38

Programming shouldn't be done in PDP macro assembly.

Name: Anonymous 2012-11-04 20:09

TCC
output size
No.
compilation time
Yes.

Name: Anonymous 2012-11-04 20:15

>>22
I've tested it out. In every case TCC destroyed gcc often by factors of 10-50+.

Name: Anonymous 2012-11-04 20:23

It would be a fair comparison if tcc was capable of any optimization. It's a Toy C Compiler.

Name: Anonymous 2012-11-04 20:32

>>24
Everything is optimized without any flags.

Name: Anonymous 2012-11-04 20:53

>>24
Real programmers write good code.

Name: Anonymous 2012-11-04 21:00

It's a Toy C Compiler.
Or a quite good C JIT.

Name: Anonymous 2012-11-04 22:09

>>27
A good JIT necessarily performs optimizations. Otherwise you are talking about a naive JIT.

Name: Anonymous 2012-11-04 22:38

mingw gcc + msvc link:

$ gcc -nostdlib -Os -s -c small.c -ffunction-sections -fdata-sections -Wl,--gc-sections,--section-alignment,4096,--file-alignment,512

$ link small.o msvcrt.lib __main.o /entry:_start /subsystem:console /merge:.rdata=.text /merge:.eh_frame=.text /merge:.bss=.text /fixed

$ du -b small.exe
1024

Best I could get with just mingw gcc and mingw ld:

$ gcc -Os -s -o smallmingw.exe small.c -mconsole -nostartfiles -ffunction-sections -fdata-sections -Wl,--gc-sections,--section-alignment,4096,--file-alignment,512,-e,__start,merge_sections.ld

$ du -b smallmingw.exe
1536

merge_sections.ld script:

SECTIONS {
    .text : {
        *(.text)
        *(.eh_frame)
        *(.idata)
        *(.rdata)
        *(SORT(.rdata$*))
    }
}


(I still can't get rid of the .idata section for some reason, if I could the size would be 1K just like msvc linker)

small.c:

#include <stdio.h>

void _start(void)
{
    puts("Hello World");
}


And this is not using any packer or PE stub tricks, just the basic compiler output.

Name: 2012-11-04 22:59

Name: 2012-11-04 22:59

Name: 2012-11-04 22:59

Name: Anonymous 2012-11-04 23:00

>>29

$ du -b smallmingw.exe
$ du -b s

czech em

Name: Anonymous 2012-11-05 1:03

>>29
*(SORT(.rdata$*))

Why?

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-11-05 1:34

>>5
Not performance, but efficiency. I guess the better question to ask is <i>why are you using gcc</i>. That's not by choice, there's too much opensource code out there that's dependent on its features. (I'm thankful that at least gcc produces COFF that MSVC's linker can consume, and not its own format.)

>>6
I don't care about "scalability" or whatever you call it, if it can't do a basic "Hello World" at least as efficient as MSVC, then it's worse. The majority of the projects I work on are <32KB anyway.

>>19-23
TCC has no optimisation at all. So long as it's not too much, I don't care if a compile takes longer if it can produce more efficient output.

>>29
So that's how you merge sections... can you set the section attribute to EWR too?

Name: Anonymous 2012-11-05 5:48

Don't touch my free-software ThinkPad or try to curtail my essential rights, cretin. I will kill any intruders. You have been warned.

Name: Anonymous 2012-11-05 5:53

>>36
eat shit and die, nazi so-called feminist piece of shit

Name: 37 2012-11-05 5:55

>>36
LET'S BAN CRYPTOGRAPHY AND FOSS SOFTWARE AND GENERAL PURPOSE COMPUTERS BECAUSE SOMEONE SOMEWHERE MIGHT SEND AN ENCRYPTED MESSAGE CONTAINING A JOKE THAT MAY BE INTERPRETED AS DEPICTING HOMOSEXUALITY IN A SLIGHTLY NEGATIVE MANNER.  SUCH A DISGUSTING ACT MUST NOT GO UNPUNISHED.

Name: Anonymous 2012-11-05 7:09


SECTIONS {
    .text : {
        *(.text)
        *(.eh_frame)
        *(.idata$*)
        *(.rdata)
        *(SORT(.rdata$*))
    }
}

This will at least place the import data into the .text section, but the .idata section is still generated for some damn reason.

$ objcopy -R .idata smallmingw.exe

Will remove it, however this will cause it to crash so you need to fix the imports manually, I used PE Explorer.
Afterwords with some more post-processing:

$ du -b smallmingw.exe
687

So challenge met (kind of)

Name: Anonymous 2012-11-05 11:37

Who the hell said TCC doesn't optimize? Quote:
TCC does perform a few optimizations, such as constant propagation for all
operations, multiplications and divisions are optimized to shifts when
appropriate, and comparison operators are specially optimized (by maintaining
a special cache for the processor flags). It also does some simple register
allocation, which prevents many extraneous save/load pairs inside a single
statement.

Name: Anonymous 2012-11-05 13:00

>>40
TCC doesn't even remove unconditional jumps with offsets of zero.
jmp next_instruction
next_instruction:

TCC QUALITY

Name: Anonymous 2012-11-05 13:26

>>41
My OPTIMIZING ASSEMBLER takes care of that.

Name: Anonymous 2012-11-05 13:45

>>42
My          ANUS       takes care of that.

Name: Anonymous 2012-11-05 13:52

>>43
_t
back to /b/, please.

Name: Anonymous 2012-11-05 14:11

>>42
What if that "useless" jump was supposed to be modified to go somewhere else at runtime, so it's not really so useless? The assembler shouldn't second-guess the programmer.

Name: Anonymous 2012-11-05 14:17

>>45
That's what -O0 is for.

Name: Anonymous 2012-11-05 14:18

>>45
A C compiler that allows for run-time code modification? Sounds brilliant!

Name: Anonymous 2012-11-05 15:07

>>47
ALTER GATHER-DATA-ABOUT-ENVIRONMENT TO PROCEED TO  DISCARD-IT-AND-DRIVE-INTO-WALLS

Name: Anonymous 2012-11-05 17:01

DRIVE-INTO -Walls

Name: Anonymous 2012-11-05 18:05

>>49
#undef RIVE_INTO

Name: Anonymous 2012-11-05 18:58

You are programming on Windows, it's not supposed to be minimal.

Name: Anonymous 2012-11-05 21:19

>>35
The majority of the projects I work on are <32KB anyway.
The point still stands: why are you using a toolchain that was never intended to target these kinds of applications? Why can you not just use gcc to generate ELF on your favorite .*n[iu]x?

Name: Anonymous 2012-11-06 0:41

bampu pantsu

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-11-06 4:50

>>52
I was evaluating MingW to see if it might be better than MSVC due to all the new features gcc has. I'm not convinced it's better.

Here's the results of something less trivial (internal network testing app):

Total size(MingW): 38.0KB
Total size(MSVC): 23.5KB

Size of sections:
MSVC:
 Header 0.5KB
 .text 19KB
 .rsrc 4KB

MingW:
 Header 1KB
 .text 27.5KB (!!!)
 .data 0.5KB
 .idata 1KB
 .CRT 0.5KB (WTF?)
 .tls 0.5KB (WTF?)
 .rsrc 1KB

A closer look shows that GCC/GAS is horrible at code generation. Here is a fragment of code pulled at random from the MingW executable:


004066E8 C70424407C4000   mov       d[esp], 00407C40
004066EF E838FFFFFF       call      0040662C
004066F4 51               push      ecx
004066F5 C744241001000000 mov       d,[esp+0010],00000001
004066FD C744240C0A194000 mov       d,[esp+000C],0040190A
00406705 C744240800000000 mov       d,[esp+0008],00000000
0040670D C7442404C8000000 mov       d,[esp+0004],000000C8
00406715 A120C84000       mov       eax,[0040C820]
0040671A 890424           mov       [esp],eax
0040671D E88AFEFFFF       call      004065AC
00406722 83EC14           sub       esp,14
00406725 A360934000       mov       [00409360],eax
0040672A 8D5DDC           lea       ebx,[ebp-0024]
0040672D E9DF000000       jmp       00406811
(It takes a detour here, for no good reason.)
00406811 C744241001000000 mov       d,[esp+0010],00000001
00406819 C744240C271B4000 mov       d,[esp+000C],00401B27
00406821 C744240800000000 mov       d,[esp+0008],00000000
00406829 C744240465000000 mov       d,[esp+0004],00000065
00406831 A120C84000       mov       eax,[0040C820]
00406836 890424           mov       [esp],eax
00406839 E8CEFCFFFF       call      0040650C
0040683E 83EC14           sub       esp,14
00406841 85C0             test      eax,eax

124 bytes.

This is the same portion of source code, compiled by MSVC:

004051BF 68481C4000      push      00401C48
004051C4 FF1528104000    call      LoadLibraryA
004051CA 8B1DB4104000    mov       ebx,[004010B4]
004051D0 6A01            push      01
004051D2 68111D4000      push      00401D11
004051D7 56              push      esi
004051D8 68C8000000      push      000000C8
004051DD FF3580974000    push      d,[00409780]
004051E3 FFD3            call      ebx
004051E5 6A01            push      01
004051E7 68E3204000      push      004020E3
004051EC 56              push      esi
004051ED 6A65            push      65
004051EF FF3580974000    push      d,[00409780]
004051F5 A3F8904000      mov       [004090F8],eax
004051FA FF1550114000    call      DialogBoxParamA
00405200 85C0            test      eax,eax

68 bytes.

Remember, this is -Os so I am not interested in stupid move-to-stack tricks. GCC/GAS seems completely oblivious to push imm8 and doesn't store frequently used constants (like 0 or the address of a function) in a register. The double-indirect import call is also bloaty, being 25% nops.

Conclusion:
MSVC 8/10
GCC 2/10

Name: Anonymous 2012-11-06 5:58

>>1

there's no calculation going on in this program, how do you expect a serious discussion about it?

Name: Anonymous 2012-11-06 6:48

>54
push imm8 doesn't really exist though, it's a pseudo instruction and actually pushes the byte as a word or dword, and on amd64 it's even an illegal instruction all together.

I'm also skeptical of your code.
That looks typical of unoptimized code, actual benchmarks done shows gcc and msvc being pretty much equal in code generation performance.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-11-06 6:57

>>56
To be exact it's a push sign-extended byte constant, but it's not a "pseudo instruction" (does x86 even have those? the closest I can think is xchg eax == nop), it's right there at position 6A in the opcode map.

and on amd64 it's even an illegal instruction all together.
They really messed up with AMD64. Not going to say more about that.

actual benchmarks done shows gcc and msvc being pretty much equal in code generation performance.
Was that size, speed, or both? I don't care about absolute speed that sacrifices everything else. This is max size opts for both compilers.

Name: Anonymous 2012-11-06 9:34

>>57
By pseudo-instruction I mean it doesn't really do what it says, it does not push just a byte on the stack, push imm8 and push reg32 (with reg32 == imm8) is the same as far as the cpu goes, it's not any more efficient over a dword push if that was your concern.

gcc at -O2 and higher are the same speed as msvc /Ox

Also the reason you see those double indirection for the msvcrt calls is bcause you're linking to the old msvcrt whereas your visual studio presumable uses msvcrt100.dll and have LTO enabled.
If you link your mingw code against the latest libc and add -flto I'm certain you'll get rid of all those .idata indirections.
This is also the reason you see all that .tls stuff, mingw has to insert its own thread safe code because the old msvcrt.dll (that shipped with like win2k) wasn't particular thread safe.

If you want to use latest gcc features that msvc doesn't have I recommend using gcc for the compiler and msvc link (or crinkler if you're into tiny exe's) as your linker.

Name: Anonymous 2012-11-06 9:38

No results found for "mingw dynasty"

Name: Anonymous 2012-11-06 21:47

>>54
That is pretty gross. I miss my __watcall.

They really messed up with AMD64. Not going to say more about that.
No, please go on...

>>58
push imm8 and push reg32 (with reg32 == imm8) is the same as far as the cpu goes, it's not any more efficient over a dword push

I think you're missing the part where gcc is using mov imm32 which is fucking enormous.

Name: Anonymous 2012-11-07 0:39

>>60
mov dword might actually be more efficient than push dword because a push puts down a dependency for the esp register in regards to the next instruction (since push modifies esp)
so a series of mov dword [esp+XXX] is probably more efficient since they can be pipelined.

Name: Anonymous 2012-11-07 1:04

>>61
A series of huge instructions is less efficient because it fills the decoder and wastes cache.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-11-07 1:29

is the same as far as the cpu goes, it's not any more efficient over a dword push if that was your concern.
If you're pushing values between -128 and 127 then it is more efficient, 2 bytes instead of 5. Not sure if the decoders now do it, but you could decode and execute 4 of them with one 64-bit fetch vs only one push imm32 (and 3 bytes of another instruction.)

Also the reason you see those double indirection for the msvcrt calls is bcause you're linking to the old msvcrt whereas your visual studio presumable uses msvcrt100.dll and have LTO enabled.
They're both linked to MSVCRT.DLL, the newer VCredist runtimes are disgustingly bloaty. (You have to add an XML "manifest" and go through the whole SxS mess... do not want.)

mingw has to insert its own thread safe code because the old msvcrt.dll (that shipped with like win2k) wasn't particular thread safe.
No it doesn't, the app I compiled as a test above was perfectly fine without it under MSVC.

or crinkler if you're into tiny exe's
That doesn't target the main issue, and compressing the executable afterwards is not comparable to not emitting the useless code in the first place.

>>59
This thread is now the first result on Google for 'mingw dynasty', but I have no idea what you're talking about. Is dynasty some alternate linker or something?

>>61
Don't use "efficient" if you're only referring to "faster". Intel has spent a lot of effort on making stack operations ultra-fast, and the general move instructions are much larger than pushes, so even if they are a little faster, if they take more room in the cache less code can fit, and a cache miss is slower than anything else.

This whole discussion was about Os anyway, where the compiler should be attempting to generate the smallest, not fastest code.

Even when optimising for speed you shouldn't be choosing the fastest instructions for each little piece of work unless they're also the smallest, because a single cache miss is much more expensive than the difference between any two small instructions. Making a small section of code run twice as fast is stupid if its size grows so that it causes twice the number of 100x slower cache misses. Things like loop unrolling, inlining, etc. are in this category.

That's why global size-sacrificing-speed-optimisation, even by a compiler, is a bad idea: it makes everything "fast" at the individual instruction level, but neglects caching effects and as a result, noncritical code bloats up to compete for cache space with critical code.

since they can be pipelined.
Pipelining isn't the way to get performance now, it's parallelism. It could pipeline e.g. 4 moves in sequence, but what's even better is decoding and executing 4 pushes in parallel. That brings me back to the point above: to do that, the decoder has to be wide enough, and one that's just wide enough to decode 4 push imm8's at once is enough for only a single mov [esp+xxxx], yyyyyyyy.

Name: Anonymous 2012-11-07 1:42

>>63
push is not gonna be faster than mov because it does put down a dependency on the esp register, meaning it CAN'T execute the next push in parallel in any order it wants.
This is also why the xor reg, reg to zero out a register is not really the way to go anymore, a mov dword 0 is better because the xor will generate a dependency (i.e a strict ordering) on the next instruction using that register.
Read some of the latest optimization manuals from Intel regarding newer cpus.

Name: Anonymous 2012-11-07 2:00

>>62
A series of huge instruction without hazards are still better than a series of small ones with hazards.
We have huge caches these days, use them, fill them with instructions without dependencies so you can actually utilize every pipe.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-11-07 2:21

>>64
How about you read it?

"2.2.2.5 Stack Pointer Tracker

The Intel 64 and IA-32 architectures have several commonly used instructions for
parameter passing and procedure entry and exit: PUSH, POP, CALL, LEAVE and RET.
These instructions implicitly update the stack pointer register (RSP), maintaining a
combined control and parameter stack without software intervention. These instructions
are typically implemented by several μops in previous microarchitectures.

The Stack Pointer Tracker moves all these implicit RSP updates to logic contained in
the decoders themselves. The feature provides the following benefits:
• Improves decode bandwidth, as PUSH, POP and RET are single μop instructions
in Intel Core microarchitecture.
• Conserves execution bandwidth as the RSP updates do not compete for execution
resources.
• Improves parallelism in the out of order execution engine as the implicit serial
dependencies between μops are removed.
• Improves power efficiency as the RSP updates are carried out on small, dedicated
hardware.
"
...
"
• ESP folding — This eliminates the ESP manipulation μops in stack-related
instructions such as PUSH, POP, CALL and RET. It increases decode rename and
retirement throughput. ESP folding also increases execution bandwidth by
eliminating µops which would have required execution resources.
"

Also, Intel's own compiler uses push/pop. That should be enough evidence.

This is also why the xor reg, reg to zero out a register is not really the way to go anymore, a mov dword 0 is better because the xor will generate a dependency (i.e a strict ordering) on the next instruction using that register.

"Dependency Breaking Idioms

Instruction parallelism can be improved by using common instructions to clear
register contents to zero. The renamer can detect them on the zero evaluation of the
destination register.
Use one of these dependency breaking idioms to clear a register when possible.
• XOR REG,REG
• SUB REG,REG
...
"

I've read a lot of C compiler output in my life, and gcc's is the only one that "sticks out like a sore ARM".

Name: Anonymous 2012-11-07 2:41

>>66
Cudder, you're obsessed. Can you talk about anything besides your ugly x86? Shit is just too mundane. Go be namefag somewhere else!

Name: Anonymous 2012-11-07 3:17

>>67
Every architecture will eventually devolve into x86 level ugliness. It is unavoidable.

Enjoy your dedicated stack units, I know I will.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-11-07 3:22

ugly
It's the ugly duckling that turned into a beautiful swan.

Going to go see if LLVM/Clang is any better (hoping it is).

Name: Anonymous 2012-11-07 20:58

>>63,67
I have no idea what you're talking about. Is dynasty some alternate linker or something?
Can you talk about anything besides your ugly x86?
Nope.

http://en.wikipedia.org/wiki/Ming_Dynasty

>>64,66
>> ESP folding — This eliminates the ESP manipulation μops in stack-related
instructions such as PUSH, POP, CALL and RET.

This one reason why I dislike x86: programmer assumptions about the performance characteristics of their code don't hold from one generation to the next.  Notice that ENTER and LEAVE are totally missing from the above list. (Of course, any code that uses those will still run faster on Core than on the 286 it was originally intended to run on, so there is no real practical impact - it's just annoying.)

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-04-22 9:07

>>70
Notice that the wording is "such as", meaning "including but not limited to".

ENTER and LEAVE are still valid in 64-bit mode, which to me means they have something planned for them in the future. They might be slower at the moment but as the decode and memory bandwidth continues to narrow there's more interest in dense instruction encoding and they'll start speeding them up too. Intel/AMD aren't going to do this all at once; it'll be a gradual process with each new model they release.

(These are also fun "beat-your-competitor" instructions; it take about 3 times longer for Bulldozer to do an ENTER than Sandy Bridge, so Intel's compiler could be configured to use it to beat AMD in benchmarks involving many many function calls...)

Plotting the instruction latencies and throughputs of various instructions for different CPUs over the years could be an interesting exercise.

Name: Anonymous 2013-04-22 9:17

I prefer MinGW to MSVC purely because it knows how to use fucking long doubles. MSVC converts all long doubles to doubles for some ecchi reason.

Name: 72 2013-04-22 9:42

Example taking the sine of pi:

#include "stdio.h"
#include "math.h"

int main(){
long double a=3.1415926535897932384626433832795L;
printf("%.25g\n",(double)sinl(a));
}


Compiled with MSVC, output = 1.2246467991473532e-016
Compiled with MinGW GCC, output = -5.4210108624275222e-020

I convert to double so that printf can print it (Windows DLL printf doesn't support long double), put it is done after the calculation so it doesn't matter. MSVC output is the result that is obtained when calculation is done using double; less precise. MinGW result is correct and also the result of doing fldpi and then fsin.
I also tried using inline asm of both compilers using fldpi and fsin, and it gives the same results (I no longer have the code, but it's too complicated to program right now just to post an example on /prog/, so take my word for it).

Name: 72,73 2013-04-22 9:51

To clarify, what I mean by "using fldpi and fsin on both compilers", I mean using the "long double" variable as the medium. On MSVC "long double" always behaves as if it was just "double" - even sizeof(long double)=8. Fldpi+fsin of course always gives the correct results when coded in pure asm, but what's the point of a C/C++ compiler if you're just going to write pure asm?

Name: Anonymous 2013-04-22 9:55

>>74
Yeah, it's a compiler bug. Even so, you use high level languages because it's such a hassle to write larger software in ASM. With free software, you can get it fixed. With MSVC, all you can practically do is beg to get it fixed.

Name: Anonymous 2013-04-22 20:01



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 20:09



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 20:14



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 20:19



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 20:23



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 20:28



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 20:33



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 20:39



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 20:44



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 20:49



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 21:03



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-04-22 21:11



Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop


Searching for legit Microsoft Product keys, Windows 8,7,Studio,Server etc.?

 Mail me at jeremiahgoldstein@hotmail.com

 25$ a pop

Name: Anonymous 2013-09-01 15:07


 It is therefore assumed by physicists that no measurable quantity could have an infinite value, for instance by taking an infinite value in an extended real number system, or by requiring the counting of an infinite number of events.

Don't change these.
Name: Email:
Entire Thread Thread List