Forgot your password?

Comment: Re: Uh, sure.. (Score 1) 359

I was expecting this one about assembly. There are a few things about this one though, the gcc one is a hassle to get working exactly right. (Configuration) The msvc one works easily and is predictable. You need the inline assembly to activate/configure the device. After that you usually switch to full asm functions to fetch and write data and c++ functions for everything else. The register blocking and overwriting issues most people mention usually results from incompetence with assembly more so than from compiler behaviour. But that's an educational flaw in the current generation of programmers. Building up an OS from the bare metal ought to be a graduation requirement. To get around it in the x64 versions you need to get a bit creative with linking though. But I'm so not getting into explaining that one. Lets say very few x64 device drivers need more than the standard x86 instruction set. Weirdly enough it still takes less time than switching to GCC, WDK and GCC really do NOT like each other. We tried it once and lost a lot of time and returned to msvc. The macros don't work, GCC also has very peculiar behaviour that you need to control with switches. (A colleague started calling it GNU Switch Roulette. ) Ideally we'd just scrape both compilers and start from scratch, but then we'd end up with windows compatible LLVM I guess. Or I should stop getting involved with these coding projects and stick with hardware.

Comment: Re: Uh, sure.. (Score 1) 359

May I be as bold as stating that you fail to consider everybody's requirements, or at least that we are looking at this from a very different perspective?

The main OS on the market at this point is Windows, both for professional and personal use. In light of this fact you can scrap GCC and LLVM from the list already, GCC creates large cumbersome executables on windows. Sure MinGW isn't bad for meddling around and some small executables. But I wouldn't want to use it to compile things where performance matters, I've tried on several occasions. I must say I find GCC's capability to deal with the Windows Platform SDK quite remarkable at this point. But the end-performance is icky at the best of times. LLVM simply does not have any real windows port that's stable and performant enough for production software.

Before I continue I should probably also mention the code I write is mostly meant for hardware interfacing (I guess you could say drivers to some degree), simulation, and data visualization. All these things require high-end performance which I simply cannot find in the GCC or LLVM ports to Windows. And before you go off making bold statements about Windows not being fit for these sort of jobs, I disagree heavily. If the program that needs the simulation code runs on windows it doesn't make sense to run it on anything else than windows for small to medium scale simulations. Interfacing to remote systems is a hassle and generates a large overhead. For the very heavy lifting using C++ is pointless, Fortran still takes the gold trophy home in that area for me.

And while to the untrained eye the machine code generated by GCC and MSVC might look very similar, MSVC simply generates better code for hardware interfacing, especially its more predictable what happens when you use in-line assembly. The windows port of GDB also fails miserably for these sort of applications, while the MSVC tool chain does a decent job. For simulation it really starts to show though, MSVC simply generates more efficient code than GCC for Windows. Do note that this requires configuring the compiler correctly, something that's trivial to do for MSVC but requires digging through documentation for GCC. Other alternatives like the compilers produced by WATCOM, Digital Mars, Mentor Graphics, and a few others simply don't cut it most of the time. They're either unable to produce code that's capable of using all the resources efficiently, or behave horribly when things like CUDA are invoked. Then there is also the entire issue of data visualization, one of the most important aspects of software development in my opinion. On Windows its either use DirectX or die trying. I agree this is mostly due to Microsoft's doing but we're stuck with it. And no matter what you do, nothing quite beats MSVC when dealing with DirectX.

This also brings me to the point of more common desktop applications, the MSVC standard library works. If you try to use it like the one produced by the GNU project you'll indeed end up in trouble. Not to mention that GTK is a horrible badly documented excuse for a UI library. Qt is better but has licensing issues all over the place. Wx is lacking features in a few important areas. If you use MSVC it knowing its strengths and weaknesses you have a great *little* tool chian at your disposal. Tie it in with the full Windows platform SDK and you have something you can quickly produce a large application with. Frankly I don't care about the C++ standards, I'm very pragmatic about these sort of things and I'm happy if things work well. If I don't have to dig under the hood too much I'm happy. I don't care about the compilation speed, incremental building works very well and my desktop is more than quick enough for 99% of the cases.

Comment: Re: Uh, sure.. (Score 1) 359

I think my first statement is quite obvious, but we don't talk about that. ;)

Why should we care that the source of a compiler is open? In the end of the day we care about these things:
1) If it goes wrong do we have somebody to help us that we can call?
2) Is there a quick development cycle possible? (Not having to read through hundreds of pages of manual)
3) Does it work on Windows?
4) Does it integrate well with existing toolchains?
5) Are there any ridiculous limitations?
6) Can we use it without causing a licensing nightmare?
7) If it does go terribly terribly wrong, do we have somebody to shout at?

Please note how access to the source code isn't part of that list. We're so heavily occupied that even if we had the source code we don't have time to look at it unless we plan it in our agenda several months ahead of time or do it on our own time. But lets get back to opensource compiler toolchains! GCC is hardly user-friendly, huge dependency chains for all the related tools, and don't get me started on GNU autoconf. I'll agree LLVM isn't a bad compiler, but it doesn't work well on windows which kills any use we have for it. (Because lets face it, the majority of the population uses Microsoft Windows.)

Comment: Re: Uh, sure.. (Score 1) 359

I could share my experience of working with programmers, but we don't talk about that. Half the time the opensource toolchains require hours of reconfiguration for specific tasks. Not to mention the bloated MSYS ports, which frankly are a far worse issue. (Most people use windows. ) Saying things are good because they are opensource is foolish. The end result is what matters.

Comment: Re: Uh, sure.. (Score 1) 359

Funny you should say that. MSVC is one of the best compilers in existence for C++. Extremely good optimizer, brilliant debugger, extensive standard library, very forgiving for small mistakes, clean output well suited for pipelined execution and much more. It beats the GCC toolchain easily in every way. Only intel composer does slightly better, and maybe a few very specific ones on very specific code.

Comment: Re:Administrators (Score 1) 538

by solidraven (#47292225) Attached to: Teaching College Is No Longer a Middle Class Job
I heavily disagree, to find the cutting edge you often need to look at where industry works together with academia. Then again, such projects rarely get advertised due to the amount of IP involved. Another thing I've seen is that some companies "outsource" their R&D department in the sense that they hire the staff but place them at a university, or at least on a university campus, and use the equipment there or at least buy time on it. But it really depends on the industry and the size of the company obviously.

Comment: Re:Bios code? (Score 1) 533

by solidraven (#46019281) Attached to: Ask Slashdot: What's the Most Often-Run Piece of Code -- Ever?
Each time it comes out of hibernation those routines are executed in a lot of cases. Plus during critical procedures you must always disable interrupts, hence it's a very common procedure. And you forget that your computer also contains several microcontrollers, like the 8051 is often used as USB host.

Comment: Re:Bios code? (Score 1) 533

by solidraven (#46002069) Attached to: Ask Slashdot: What's the Most Often-Run Piece of Code -- Ever?
Microcontrollers are present in huge numbers, the most executed code is probably somewhere in a 4-bit microcontroller in your washing machine or microwave oven. As such my entry for this one is the start-up sequence of a microcontroller: disable interrupts, configuration code, enable interrupts. Another likely candidate is the 8051 series microcontroller, that one has been around for decades and it's still being made and improved. So to be precise, configuring the timers and interrupts of the 8051 family.

You must realise most graphics cards actually don't execute that many instructions. A graphics card can process a lot of data at once, sure. But it's a case of SIMD more often than not. So the actual number of instructions executed is quite limited versus the amount of data.

Anything free is worth what you pay for it.