Elysian Shadows

GyroVorbis wrote:

xx6heartless6xx wrote:

GyroVorbis wrote:

xx6heartless6xx wrote:Do you need to be a really good programmer to start doing assembly?

God no. I know plenty of electrical engineers that write assembly and can't code in any higher-level language for shit.

Your hardware and architecture knowledge are way more important than you software knowledge when you're that low level. Lots of your C-style procedural organization constructs may carry over, but object-oriented experience doesn't mean anything in assembly.

Assembly allows you to directly interact with the hardware right? How come electrical engineers use it a lot besides maybe the speed benefits?

They make the hardware.

Duh! Man I feel stupid. But assembly looks pretty interesting and useful in the future. and the book DeathNote recommended looks good. I'll definetely check it out

xx6heartless6xx wrote:Do you need to be a really good programmer to start doing assembly?

Assembly is very good to know (in my opinion at least). But the main thing you need to remember is that different architectures have different syntax, different interrupts, etc; I have a general understanding of x86 using MASM (www.masm32.com) which is Intel Syntax. With all these high level programming languages it makes assembler unattractive to many people. Maybe because instead of it all being done for you, it actually requires you to put that extra effort in for the final result. I personally like that "extra effort" that's involved. It makes me feel that i actually accomplished something incredible. Just my thoughts.

Folks, you really need to be pragmatic about this. The case where you'd code assembly "because it can be fast" is rapidly waning. As a matter of fact its not as easy as simply inserting inline assembly blocks into C code anymore. If you compile against x64 with any modern IDE, you won't even be able to use inline assembly. It has to be built and linked completely separately.

I've already ported a metric assload of some pretty stressing graphics code from DX/Win32 to Java/android. We haven't seen any performance bottlenecks yet from the API level code. It just goes to show you that the lower you go does not always mean that the code will execute faster. As a matter of fact, unless you really know what you're doing there's a VERY good chance you're going to make your code significantly slower. You might be surprised with some of the ingenious code these JIT languages come up with.

Now there's an interesting examination that goes along with this. That is the expected efficiency gain vs the man hour input to the code. Generally it takes 10x as long to write assembly code that a high level language can do in 1x time. So what this says is that you simply don't optimize until its evident that you need to. This is where proper and effective code profiling comes in. A step beyond debugging which is really what will separate you from people who simply "code". You need to be able to interpret what your program is doing, and until you can do so, coding assembly may be a monolithic waste of time.

So why would anyone code assembly anymore? Fact is that even though you might have seen it in a fair bit of code 10-15 years ago, you just don't see it now. You really don't. The only real reason that it happens is if you're coding on an architecture that simply doesn't ship with a higher level language binding. I'll admit that even THIS is becoming rare as I have not worked on a chip yet that didn't have at least a C API. But, you know....it DOES happen.

Sure it sounds chic, but I wouldn't invest a plethora of time in learning assembly at this point in time. A working knowledge of hardware is necessary and DOES translate to the higher level languages (even Java and C# if you're very critical) which would in turn probably benefit you 10x more than anything else.

One of the finer programmers I've worked with, Rich Harvey, once told me: If speed is your problem and you can identify the bottleneck then chances are you just need to write better C-code.
(What he really means is "high level code".....yes......"C" is high level code)

The man was right.

I agree with pretty much all your points qp. I think that as a learning tool assembly helps you write better high level code. You said that hardware knowledge is essential, i couldn't agree more but I think that assembly is the best way to quickly learn about hardware. Plus it gives you an appreciation of higher level languages because it's sooo much easier to do ...well... anything.

GyroVorbis wrote:This article isn't talking about the demise of assembly programmers. It's talking about C/C++ programmers. It isn't talking about optimizing things with inline assembly. It's talking about tasks that we all take for granted (due to the low-level nature of game development) like manual memory management, pointers, cache alignment, and basic architecture. Modern JIT languages like Java and C# abstract these away and keep developers a safe distance.

And while I'm not implying at all that this is a bad thing (because they can definitely boost production), it's just sad to me how many higher-level JIT developers are willingly ignorant of how anything works outside of their own scope.

As for assembly being difficult, I've always said that with a little bit of hardware knowledge, it's the easiest language that you could ever learn. What's so hard about a language with about 20+ "commands" (RISC-style architecture) with preset functions, fixed argument types, and a dozen or so registers? Nothing. Once you get past the initial "holy jesus, computer hardware" jump into the architecture, you'll realize that once you know one assembly language, you're just a processor/microprocessor document away from knowing them all.

Writing assembly is fuck easy. Writing USEFUL, nontrivial things in assembly is HARD.

I'm culprit of that. But I'm not a computer science major.

In my experience the problem stems from schools designing their rhetoric based on easier languages. Any of the required introductory programming courses that I had to take in my CIS program were a choice between Java and VB.Net my first two years and then C# in my second two years. But even I know how incredibly stupidly easy it is the learn something like Java and C#. I would be curious to find out what the curriculum is like for CS majors here. I know they are forced to take an introductory Java course, and later in their 3rd year an Assembly course, but any of the other course descriptions only described "object-oriented language", which I assume would be C#.

Let me also take a step back and talk about the bigger picture like qp, because it probably seems like I'm advocating jumping straight into assembly, when I don't. I agree with him. I was the one who originally said that the "low-level" developers of the article were referring to C/++, not assembly. This topic then took a turn into the world of assembly, so I kind of rolled with it.

I definitely think it's sad that so many CS students are graduating without knowing how the fuck to handle pointers. I think it's sad that they don't know how to use malloc and free or new and delete. I also think it's sad that simple architecture concepts like a static array or vector being a more cache-friendly structure than a list are either no longer addressed or not stressed enough. These are computing fundamentals that are just as (if not more) relevant to the software world as they are the hardware. I don't think it's sad that CS students graduate without knowing how to write x86 assembly (although Kendall's CS program here DID make her take an x86 class).

Assembly is 99% of the time too low-level to be relevant to a software engineer/computer scientist. If you took an algorithms class, you'd know the the time complexity of an algorithm can be (and usually is) many orders of magnitude more important than the clock-cycle execution time of the individual instructions. Combine that with the fact that the compiler usually can out-optimize your assembly--and I'm not just talking about shitty assembly.

With that being said, there are objective times when assembly does offer a great benefit: hardware acceleration. When the goal is to utilize a piece of hardware fully in a manner that the compiler is unaware. I would like to use an example from ES on the Dreamcast or PSP here, but I'm sure that somebody would bitch that the two are no longer relevant. So I'll choose another. Last I had heard, the OpenGL ES implementations on the iPhone/iPad and Android are NOT hardware accelerated. They are using the FPU to perform a shitload of calculations when the ARM Cortex processors come EQUIPPED with a vector processor and SIMD instructions for utilizing them (NEON). In this scenario, you have DEDICATED HARDWARE that was literally created for vector/matrix and matrix/matrix transforms that the compiler is not taking advantage of. The only way to even access this is through ARM assembly. THIS will give you an objective, major performance increase. Most embedded devices these days have SIMD extensions like this. Granted there are still bound to be libraries implementing this for you in assembly, but it's still a really good reason to drop there.

These are small, objective tasks that are implemented in inline assembly. You still have an overlying C/++ software framework. Throwing that away and deciding to do everything in assembly because it's "hardcore" or "will be faster" is retarded. That's like pissing on the last 10 years of higher-level software advancements and deciding to go back to the days of caveman coding. Your project and productivity WILL suffer.

I'm probably also a little biased on the subject. I'm not a CS major, I'm a computer engineer. I work at a telecommunications company working at the driver level for network processors. I've found a job that really does require I be at this low level (because I dig it), when the majority of software engineering do not. The majority of my coworkers are electrical engineers assembling boards and writing VHDL for FPGAs. For every new microprocessor or piece of hardware, there will still always need to be a driver developed to access/communicate with the hardware. That's an assembly/low level C task that isn't going anywhere. It's easy to forget that there's an entire embedded development world out there that DOES give a shit about this kind of low level work, just because most of our software is running on a PC these days. We make routers and networking equipment at my work. Think of every device that you own with an embedded processor inside of it. That industry is growing.

Just to give another point of view.

I work for a very large company that makes their own hardware, and with that writes their own OS's and drivers and all that jazz.
most of what I've seen, certainly 99% of the kernel is in C++.

Also, I guess you could call me a "software engineer", altho I think titles are just buzzwords, I am not a hardware guy. I have one of those silly old CS Degrees, and Im pretty sure I see and work with more assembly than your average "computer engineer", probably you too Falco. (No, im not claiming to know more about hardware, and I'd actually really be interested to know just how much assembly you work with)

Also, asm of C++ code is not this easy 20 command jazz. It's a mammoth task to wrap your head around it.

Anyways, dont get pulled into this illusion that you'll never work or have to work with ASM. In most cases you will. And if you want to work in the OS field, especially working on the kernel, you might as well know 80 percent of your time will be working in a debugger, 99 percent of the time, it will be postmortem because you'll be working on a core dump from a system crash, you probably wont have symbols, so you'll have no option but look at ASM. I could go on and list all the bleak details, but im sure you get the picture.

avansc wrote: and Im pretty sure I see and work with more assembly than your average "computer engineer", probably you too Falco. (No, im not claiming to know more about hardware, and I'd actually really be interested to know just how much assembly you work with)

I'm a driver developer on a GPON (gigabit passive optical network) ONT. It's a kind of fiber optic-based router delivering voice, video, and data. I work at the MAC layer with PPC and MIPS GPON processors who have special registers, opcodes, and DMAs for transferring/receiving fiber optic data. I generally don't write any assembly, because the registers are all accessed as memory-mapped IO, but I am at about as low of a level as C can go, working with ISRs and talking directly to the devices.

Our company also develops its own operating system (AdtranOS) for its routing/switch products. Since we work on embedded MIPS/PPC platforms, every high-level software engineer is technically also working on the OS itself. The kernel level of the OS is about 80% C with 10% platform-specific assembly routines and 10% C++ wrappers. All higher-level feature-based development is done in C++.

My officially title is "software engineer" as well, but I'm usually down at the driver level in C here.

ALL of our developers are "embedded systems" developers, but almost none of them ever even come into contact with assembly. I really disagree. UNLESS you are working with operating systems, drivers, or specialized embedded platforms you won't even need to drop to C, let alone assembly.

Also, any embedded JTAG-based probe/debugger worth its shit can step you through C/++ symbols from a coredump of the same image without making you have to trudge through assembly.

GyroVorbis wrote: Also, any embedded JTAG-based probe/debugger worth its shit can step you through C/++ symbols from a coredump of the same image without making you have to trudge through assembly.

As far as I now JTAG is only for live debuggin. We dont have that luxury since 99 percent of our problems are not easily reproduced. Our systems fail out in the field, we get a report from the customer. When the system failed it essentially dumps eveything that was in memory into a special place, that gets recovered. its just a snap shot, sometimes you only get partial dumps, these are also release builds, so there are no symbols. the only way you can get the symbols is if you compiled that particular version with the -ggdb flag that will produce a .gdb and actually still have that gile. That file that contains a lot of things, including the symbols.

what you are talking about, especially using a word like "step" is of a live debug. When you do whats refereed to by some as a post-mortem debug, you have a snapshot and thats it.you have to know how to traverse the dump. to do that efficiently you need to know the code well, know the actual instructions, know the impact of 32 vs 64 bit, etc etc.

Actually did something interesting today. I had a timeout error, so I decided to print all the traces, basically printing all the threads. I dumped it to file and decided to to search to see if there were cenrtain race conditions and what not. Anyways, took like 5 min to run trace-all and the file ended being like 3-4MB.

Sounds like you are doing some interesting stuff, keep us updated of your endeavours.

I'm a newbie, I have read the whole conversations here, and I don't know if I should start learning some Assembly for, like everybody says, understand more and feel no shame. I am learning C++ and Java, and I had not know what Assembly until i read this post. Please let this poor heart know what to do

If you're a newbie, you probably want to stay the fuck away from assembly...

RyuTran wrote:I'm a newbie, I have read the whole conversations here, and I don't know if I should start learning some Assembly for, like everybody says, understand more and feel no shame. I am learning C++ and Java, and I had not know what Assembly until i read this post. Please let this poor heart know what to do

OH TEH NOES JAVA D:

I guess, for an average software engineer/programmer it is enough to know that there exists such an old thing called Assembly language and it can get close to the underlying hardware without any higher level overhead and thus it allows to optimize time-critical parts of your code. And that's it, I guess, no more knowledge is needed nowadays

And for some programmers this knowledge might be even harmful. If someone is trying to use Assembly in some average game or in a business application to make it run faster, it most probably means, he/she is optimizing wrong piece of code. After all, there are some less masochistic ways to boost performance, like MMX, SSE and other SIMD family instructions, which can be used from C/C++. If inexperienced C/C++ programmer (like me ) will try to write Assembly for optimization, I guess, there is a great chance that he'll get a code which is much less optimized than the C/C++ compiler spits out

Although understanding a bit of Assembly might help to make decisions about your C/C++ code. For example, if you have written some tricky stuff that your C/C++ compiler cannot optimize for you, you can inspect, how your code looks like when compiled to Assembly. If you have at least some minimal understanding about what is going on, you can rearrange your C/C++ code in a way which is less confusing for the compiler optimization algorithms and thus you'll get more effective result out of your C/C++ code by knowing something about Assembly and how the compiler works.

I think it's funny that starting off in programming, pointers seem so "scary" and "complex", but as time goes one, you start to learn that EVERYTHING is a pointer in one form or another.

Knowing low level concepts helps you write better code. Obsessing over low level concepts makes you write wasteful code.

We should feel sorry for those who started with Java / C# / PHP and do not know anything about C++. Some of those programmers have no idea what is a pointer and what is a memory leak, although they are using pointers and sometimes they create memory leaks, which are hidden somewhere deep in .NET / Java core libraries, so those leaks are a pain in the ass to detect.