Is Assembly Programming Still Relevant, Today? 676
intelinsight asks: "Consider the following question given the current software development needs, and also the claims of the Assembly lovers for it being a language that gives one insights of the internal working of a computer. How relevant or useful is it to learn Assembly programming language in the current era? "
Yes. (Score:3, Insightful)
Isn't it the root of all programming languages?? (Score:5, Insightful)
You should not learn it.. (Score:5, Insightful)
Please continue to treat both computers and the tools you use to program as magic black boxes.
That way old dogs like me will still have a job.
For most programmers, no. (Score:5, Insightful)
Honestly... (Score:3, Insightful)
Also, a lot of embedded work is still done in assembly because with a lot of low-level industrial work having very precise clock-counts on everything is very important.
Very relavent (Score:5, Insightful)
I would not encourage universities to start pumping out CS graduates who have never seen assembly laguage, and don't expect it to phased out of the average Electrical Engineering curriculum any time soon.
Frankly, I don't think it's a very good question. It's sort of like saying, "Given that we now have calculators and computer algebra systems that will do the math for us, is it really worth it to waste students' time learning the nuts and bolts of mathematics?" It has been my (limited) experience in software engineering that knowing how something works on a deeper level will almost always be an asset, and at the worst have no effect at all.
Yes (Score:5, Insightful)
In other words, yes, there are good reasons for knowing assembly. Whether or not you'll actually use it is another matter entirely. Just depends on what you're working on.
Actually I wouldn't be surprised if in about 10-15 years assembly programmers are in higher demand since none of the CS schools these days ever teach assembly anymore.
Of course it's relevant. (Score:2, Insightful)
How do compilers know what to compile to? Magic? Imagine if all the assembly programmers died: who'd maintain & update compilers, embedded devices, many realtime instruments, etc. ?
Re:Isn't it the root of all programming languages? (Score:5, Insightful)
Re:Assembly _programming_? (Score:5, Insightful)
That's a pretty fine line there. If you can understand asm well enough to debug such issues, I would argue that you also probably know enough to write it, or at least very nearly so.
I would say that you need to know how to program in assembly language, though it doesn't really matter much which ISA you use---MIPS, x86, PPC, ARM, whatever. What matters is the ability to understand what's really happening at a low level so that you don't do stupid things in high level code that cause your machine to have a seizure.
For example, once you understand that your CPU only has a limited number of registers, you'll understand why (on some CPU architectures) it is a good idea to limit the number of function arguments so that they can be passed via registers, and that you should put the arguments that you are most likely to use at the beginning of your prototype so that they have the best chance of already being in a register.
Re:Yes. (Score:2, Insightful)
Re:You should not learn it.. (Score:3, Insightful)
Anything else, is just-- pshaw... Black boxing it.
Re:You should not learn it.. (Score:5, Insightful)
Re:All's quiet (Score:5, Insightful)
Re:Yes. (Score:5, Insightful)
as in your example, too many people code like the only platform is the multi-GHz PC.
even a year doing tools in Graphing calculator basic will teach appreciation for not wasting cycles doing everything the lazy way, 'cause sure, you usiung strcat doesn't slow the system in a noticable way, but when half the processes running are using it, and using it in "hotspots" suddenly you need a new machine because it's just not fast enough.
Internal combustion engine alalogy (Score:2, Insightful)
For most drivers, it's a curiosity.
For most auto mechanics, it's somewhat useful.
For anyone doing engine repair, it's very important.
If you are programming at a hight level like Java,
It's only when you are using a language like C where knowing how the chip works can actually help you write your code does it really matter.
Anyone doing systems programming, real-time programming, or anyone who needs fine control over their program's execution should learn assembly.
For non-programmers and very high level programmers, it's about as useful as studying Shakespeare or business law. It'll make you a more well-rounded person but it won't help your code run faster.
Re:For most programmers, no. (Score:5, Insightful)
I don't think that's the case. It really depends on what you want to do. Typical desktop applications don't need any assembly language, nor in-depth knowledge of how the CPU works. In fact, it's probably a bad thing to worry about things like this — premature optimisation being the root of all evil and all that. You don't want to put a lot of work into making your application 1% faster and then realise you've ruined your portability.
In fact, these days, there's a case for even doing away with languages like C for a lot of desktop applications. With the speed of today's computers, if you can write your application quicker in a scripting language, it's a worthwhile trade-off for many organisations.
Sure, if you want to work with operating systems or things like games where performance is critical, then knowing assembly will make you a better developer even if you don't end up using it. But most of the software industry is working at a level far higher than that, and if you are at that level and making your decisions based on what instructions the CPU is getting, then you're probably doing a worse job than somebody who is entirely ignorant of assembly.
Re:easy as 1 2 3 (Score:2, Insightful)
Curriculum here started with learning about what a gate was, how it was made from transistors (which were magic black boxes then), from gates we learned adders and other MSI devices, and eventually got to an abstraction of a microcomputer. Assembly then was a Godsend and now using that same assembly language, we've implemented C.
Point is, reference a school for electrical engineering, make a better choice than masking Duke to the country. I mean, look here at State, Ga Tech, Va Tech, MIT, Stanford, Princeton, USC, etc.
Re:Yes. (Score:3, Insightful)
Depends on what you mean by a good programmer (Score:4, Insightful)
The C Conspiracy (Score:4, Insightful)
Seriously, assembly is important for all the reasons you noted, but also for some others. If you know assembly, the chances are:
All software engineering, computer science and programming courses should start by requiring people to program a non-trivial application on an ARM processor, or something with an equally limited instruction set, in pure assembly. Why? Because then you get people who think, who program with care and forethought, who think of bloat not in terms of adding more RAM, but in terms of opportunities for bugs, glitches and gremlins. Sure, you'll get more dropouts. The computing world doesn't need more code monkeys, so it's no loss if they did. Who needs a society of half-baked, semi-literate coders?
This is not elitism, because I'm not saying that anyone should be excluded from the profession. I don't think they should. What I do think is that society needs to make damn sure that the typical coder isn't the worst coder, which is what you get if people are trained to NOT think but to let the computer do the thinking for them. Windows may act like a HAL-9000 at times, but trust me, it isn't remotely capable of anything resembling thought. A bad design or a poor implementation will not be rectified by some magical intelligence in the machine, because there isn't any.
Re:Yes. (Score:2, Insightful)
Wait a minute. You're going to go all the way through design, design review, and code it up, all based on a "good feeling". And THEN you're going to check it's efficiency with a profiler? You take "iterative" software design very literally, don't you.
Re:Yes. (Score:5, Insightful)
Programming in a high-level language is more like doing basic maintenance on said car. You definitely need to know something about how the car works, and the more you know, the more work you can do on that car yourself. Programming in assembly is sort of like taking the engine out and repairing or modding it. You may never need or want to do that, but knowing how an engine works on a detailed level can help you diagnose and remedy things that don't actually require going to those lengths. Similarly, knowing how a microprocessor works can help you understand more about what you're doing when you program in a high-level language.
It also gets you into a mindset where you're thinking about this sort of thing, which is why assembly should still be required teaching in an undergraduate computer science curriculum.
Re:Yes. (Score:5, Insightful)
But if you're going to program in Groovy then you should know Java and perhaps JVM IL. If you're going to program in C then you should know assembly. If you're programming in assembly then you should know about how CPUs will reorder your instructions etc. If you're building a CPU, then you'd better know physics.
I really don't think that if you're writing an app in Rails/Javascript/SQL you are going to achieve any performance or debugging benefits by understanding assembly language. It's just knee-jerk to say that every programmer, no matter what they do day-to-day should be knowledgeable about assembly. The same effort expended learning about the layer UNDER your development environment would have a much better payoff. E.g. a Javascript programmer reading the Firefox source code (or at least benchmarking FireFox and IE on important operations). With each level deeper you go, you achieve quickly diminishing returns.
Re:Yes. (Score:5, Insightful)
here is a side scroller i made written all in assembly (includes animated screen shot)
http://www.ticalc.org/archives/files/fileinfo/232
The things I learned:
1. 4mhz processor is REALLY fast!
2. How the stack works.
3. How absolute and relative jumps work.
4. How to create "objects" and implement "methods"
5. How the smallest variable, the register works.
I have to say that after making games in assembly, I am actually disappointed in how well the current consoles handle them. I would expect them to be able to crazy things with the hardware they are given. That is also why I am interested in the ps3, it forces programmers to understand the underlying hardware.
Still relevant, but... (Score:5, Insightful)
But two things come to mind:
1: Handcoders can code better than good compilers?
Yeah, in some cases after a lot of refining. But it is not as easy as it once was.
Compilers have gotten much better and processors have gotten a lot more complex. It's not just "how many clock cycles does this instruction use?", you also have to take various forms of micro-parallelism (pipelining, branch prediction, etc.) and cache hierachy issues into account.
2: It's good to know what goes on under the hood, sure.
But in many, many software developer tasks, early optimization is the root of all evil.
I would actually much rather recommend a top-down approach for most problems, abstracting away low-level details, rather than going bottom-up. The teaching approach of the great "Accelerated C++" comes to mind.
A lot of developers that know a little or a lot about low-level programming write less than excellent code in other regards (algorithmic complexity, design, re-use, etc.) and they can't seem to stop focusing on performance throughout the process.
For most problems, performance isn't critical, and even when it is, it might be better to look for algorithmic enhancements (lowering complexity) rather than do low-level fiddling.
Re:Yes. (Score:4, Insightful)
It's also handy for sanity checking when a quick calculation shows that your algorithm which works fine for n=10 will take something in the order of three years to complete for n=1000.
Re:All's quiet (Score:5, Insightful)
I see it this way: assembly is still used today, but only in a smaller niche. But that's not the only reason it's relevant. I think it's a good knowledge to have, even if you'll never use in practice, but it's concepts help you understand the whole. Much like Math, or basic Physics.
Re:All's quiet (Score:3, Insightful)
But, shaders are hardly written in assembly anymore, for all the good reasons.
Re:You should not learn it.. (Score:4, Insightful)
Programming in Assembly language is kind of like.. (Score:4, Insightful)
Also, it's good to remember that Assembly language is just one more tool in a programmer's tool box. I wouldn't write throw-away scripts in Assembly language, just like I wouldn't use C. I'd probably use Perl, Python or shell script, as necessary. When you need to hand-tune that algorithm to get that last little boost in performance, being able to drop down to Assembly language can save the day. Too bad it is a dying art.
On another note, I agree with the other posters that said learning Assembly language allows you to learn the hardware better. 8086 Assembly language was my second language (after BASIC), and I used it for several years, until I started using Windows and found it was much easier to write a Windows program in C
Re:debugging (Score:2, Insightful)
Re:Well, no. (Score:2, Insightful)
Re:Yes. (Score:3, Insightful)
Answer to "What's hard about pointers?"... (Score:5, Insightful)
There are people who cannot grasp the difference between "a thing" and "a respresentation of a thing". In fact, there was an entire century where almost the entire school of French philosophers were unable to grasp that there was a difference.
For pointers, it comes down to realizing that a pointer to memory is not the memory, it's a representation, and the real memory lives somewhere else: at the dereference of the pointer. And at that location it takes up real space. And so does the representation (but it's comparatively tiny).
The ability to make this disctinction comes naturally when you've written assembly code of any complexity, since you've had to manage the memory yourself. But if you've never done that, or, worse, you've only ever programmed in languages which eschew pointers and try to pretend that their own internal implementations don't use them, even if they won't let you use them, well, then, you've got a conceptual problem. An that conceptual problem is going to be very hard for you to overcome.
It also makes it very, very hard for someone to understand row-major vs. column major languages, or how you would link a program in one against a library in another, and be able to usefully communicate your data between the two. Or it makes it hard to understand the difference between "call by value" and "call by reference.
If I'm interviewing someone, and it becomes clear that they need a "code interview" because some things don't add up between their banter and their resume, the first thing I whip out is a pointer problem.
-- Terry
Re:Yes. (Score:2, Insightful)
Re:All's quiet (Score:2, Insightful)
You're certainly right, but programming language extensions could get around these limitations. For instance, I think the PIC C compiler, which is not really standard C, has an extension that lets you write and install an interrupt service routine without any assembly. One could imagine such extensions for almost any hardware feature; it's just that compiler-writers rarely bother to offer such extensions.
Re:Here's another (Score:5, Insightful)
Re:Yes. (Score:3, Insightful)
No, they can't.
In the current Standings [recmath.org] for Al Zimmerman's programming contest, you see a lot of entries that have many submissions, but aren't even close to the optimal result. Even on the smallest scale, the slowest of code would go through all 20 trillion possible cominbations - the next smallest is an order of magnitude larger, and anything larger is within don't-even-bother territory.
And yet, there's a person who has effectivly maxed-out their score, with a significant lead in the third category compared to the many other submissions. While he has at least one non-top submission, it's not something obtainable just by throwing as much computer power as possible.
Yes, learn it in context. (Score:5, Insightful)
Given all of that, assembly language *is* the hardware/software boundary. It's where all of the fancy abstractions from CS dissertations meet reality. Understanding computer architecture is a huge asset as a software engineer, and to properly understand how software and hardware interact, you have to learn at least one assembly language. There is no alternative. For most people, it is an unpleasant experience, but the payoff is enormous. The learning process that you undergo while learning assembly will change the way that you see your software and will help you understand why your code is so slow and how to make it fast by design.
I have one last point. When you tell a potential employer about the low-level stuff that you know or work that you've done, your assembly skills are a proxy for understanding how hardware works (at least to interviewers with half a brain). If their software needs to run fast, they'll be happy that you understand the deep magic of hardware.
(Incidentally, I think that the fraction of software jobs that require an understanding of hardware and knowledge of assembly languages, linker internals, etc., are the only fun ones and the only ones worth having. So I learned MIPS, ARM, PowerPC, and TMS320C6 assembly, and they have all served me very well because I don't have to refactor C# for a living.)
Re:YES! (Score:1, Insightful)
Yeah, right, let me go and find myself an IBM/360 to get exposed to... "Seriously" - you are suggesting to ignore, what, 90% of computers in the world - hell, the one sitting on your desk.
How can this be serious (or insightful).
Efficiency sometimes irrelevant (Score:5, Insightful)
This is particularly true for programs that
Re:Yes. (Score:1, Insightful)
I am not a C programmer; I learned a bit of C, a little more C++ and a small bit of assembly either on my own or during various courses at school. I understood your explanation fine. Why do you think somebody who is otherwise good at C would not understand if explained to them in precisely that way?
I don't buy this at all. I know it's a fairly lame example, I doubt you'll find any programmer who couldn't tell you that "x = x + 1; x = x + 1; x = x + 1;" is going to be a quicker than "while(x < 100000) x++;" even though the latter is less lines of code. I also find it hard to believe that they wouldn't be able to abstract that concept more to understand that two ways of doing things don't always work equally fast. Heck, hasn't just about EVERY programmer at the very least had a basic introduction to sorts? Even if they never profiled them in any way, I bet every programmer at least knows that there are multiple algorithms available that would give the same result with the same input. The logical reason for that is that one is faster than the other, either generically or in some special use case.
If you want to argue that they won't know which is which, okay. I'm not sure learning a lower-level language is going to help with that though.
I assume you don't mean "a good driver" in the sense that most people mean it; rather, as some sort of measurement of technical ability. This is why I don't really follow this "you have to learn it or you're the suxxors!" argument.
The things that people keep mentioning in this thread that assembly teaches--registers, stack, heap, queue, blah blah blah--can definitely be taught in abstraction, and probably much simpler than throwing an assembly manual at them and telling them to go to town. In fact, I would be surprised if most assembly lessons/classes don't begin with those very same abstracted explanations, before or alongside the throwing them in the pool approach.
Maybe it helps them learn better, maybe it's more in depth, etc etc. Maybe it's just a really nice way to teach all of these sorts of things at exactly the same time. These are things you can argue, and probably relatively successfully. I just don't think you can really argue that it's not possible to understand the concepts if they are abstracted a little bit. Especially when you're talking about programmers who are writing in languages that are more abstracted from the concepts.
Besides which, I don't really hear anybody argue that a well-written assembly program isn't going to be faster--perhaps substantially faster--than a well-written, for example, Java program. But isn't the whole point of C, C++, C#, Java, the majority (or all) of scripting languages, etc ad naseum to get you AWAY from the assembly to varying degrees? The argument being largely that the speed increase you would get simply isn't worth the extra development time, especially on near-modern systems?
If you're coding in some niche markets, where speed is absolutely vital or direct, precision control is vital, assembly may be important. (Of course if you're writing the very lowest level things it is necessary.) Other than that, I think much more abstract concepts of efficiency, especially compared with some nice practical examples of performance testing, will do the trick. I'm not saying people shouldn't strive for efficiency, just that there are probably easier, shorter, more applicable ways of getting there.
Re:All's quiet (Score:2, Insightful)
- bit rotations => have to be coded by ORing bit shifts and masks
- bit counting (FFS/FLS) => have to be cleverly coded to avoid iterations
- locking => you need the lock instructions/prefixes of CPUs
- prefetching => idem
- memory barriers => idem
And the list is long. What do we do instead ? typically, bit operations are done by hand with 100 times slower operations and using jumps and loops while a single instruction almost always exists. Locking accesses is performed through calling functions from heavy and slow libraries such as pthreads.
It always strikes me to see code doing such a thing :
pthread_mutex_lock(&counter_lock);
counter++;
pthread_mutex_unlock(&counter_lock);
While in assembly you would be able to do this on many platforms :
LOCK INC counter
Which is basically what is done in the mutex_lock (with added tests).
We really need some C extensions to access the lower level, but unfortunately,
the trend is the other way
Willy
Re:Yes. (Score:1, Insightful)
Some might say that it's more like saying you don't need to know how to use an astrolabe because GPS can do it for you.
That analogy is just as apt.
Re:All's quiet (Score:4, Insightful)
Personally, I like higher-level languages that abstract a lot of the inner workings such as C#/.Net, Python or Java. I like to concentrate on solving problems or making things work. However without those that *DO* write in assembly, nothing I write would *RUN* anywhere.
Re:Here's another (Score:4, Insightful)
Two main programmer mindsets (Score:3, Insightful)
I'm not a great programmer, but I've always had a good "sense" (for lack of a better word) about technical things. I worked a bit at a company doing mid to high level (V)FoxPro programming. They put me on the least desired machine and I set to work. Within minutes I realized the machine was not running right, CPU at 100% or close to it most of the time. Turns out it was virus-infected (despite NAV, of course). I found the name of the EXE, renamed it in autoexec.bat before it loaded, then deleted same. Problem solved and the oldest 'clunker' became a quite acceptable computer.
I think this story illustrates the two broad classes of programmers. (1) those able to get a task done, no matter how nerdy or obscure (but who are pathologically incapable of documenting their work, or teaching others) [e.g. my co-worker who had used that computer for months or years without noticing the virus] and (2) those who are good at interface, optimization, and documentation but lack the penetrating power to solve the more difficult problems [e.g. myself -- I had to leave that job because I couldn't 'crack' the OO stuff].
Speaking to this thread's main question: both classes of programmer would need to understand some assembly, but for different reasons. Group 1ers would likely end up using it (or having to debug/change it) from time to time -- and it would be no big deal to them to learn it, use it, whatever. Group 2ers would likely want to know _when_ to use it, and probably get someone else to do that coding.
In the geek cred hungry world of
BTW, in considering where Woz, Ciarcia [circuitcellar.com], Kahn [wikipedia.org] and Hertzfeld fit into this, I think they are Group 1ers who simply took an interest in Group 2 stuff. If you can learn both mindsets, you are one powerful programming dude, IMO. [Pity that 2ers like myself can't easily (ever?) become 1ers.] Most 1ers just want to get the job done and move on, yet so much can be learned after you think you have finished your program. [MS deserves props for realizing this and assigning a second unit to work on optimizing the code already working -- Win95 crap became slightly less crappy Win98 through this process (pdf [ieee.org])]
Would you trust these professionals? (Score:5, Insightful)
* Would you want an astronaut to understand physics and math?
* Would you want a doctor to understand chemistry and biology?
* Should somebody studying to be a Literature teacher take their full set of liberal arts courses, including history?
* Should somebody earning a business degree take music appreciation?
Most of us probably said, "Yes" to most or all of those above. Even if the study seems irrelevant or too "low-level" or too "high-level" at the time, there are areas of coursework that help us understand things better.
I see a lot of dead wood in the IT industry. There are enormous numbers of people who either have no passion or who do not have a deep-enough or broad-enough knowledge of computer science to do their daily data processing job well. They are dependent on others around them for everything, even though they may be very skilled in one area.
By having both a broader and a deeper knowledge, people are necessarily better at troubleshooting and at understanding the areas outside their particular specialty. It makes them be better at all of IT and helps them do their specific role.
You should learn IT two ways -- deeply and broadly. You should deeply learn specific skills (Java/C#/Linux/Windows/scripting in Ruby/whatever) and you should learn broad skills (computing theory/relational databases/networking/troubleshooting/programming/
There is an enormous difference between training and education. Training is learning specific skills for specific tasks (narrow/specific), while education is broader and teaches you how to think, understand, and apply (broad/general).
While taking Assembly may not seem relevant at the time and you may never directly use it again, for every programming task, having a strong background in all of computing theory (including how the CPU handles its low-level instructions) educates you and gives you a deeper understanding. (Don't just be trained, be educated!)
My recommendation is the book My Job Went to India (And All I Got was this Lousy Book). If you can't afford it, read the sample chapters, especially the "Being a Generalist" and "Being a specialist" chapters at http://www.pragmaticprogrammer.com/titles/mjwti/i
Personally, unless you need the specific class/training, I'd say that FORTRAN or COBOL ought to be abolished as required material in all colleges and shouldn't be in the degree program. Those should be electives only. Assembly, on the other hand, should remain required, for a deeper and broader education. (Don't settle for a dumbed-down program).
The difference, again, is training (specific/skill-oriented/task-oriented) vs. education (general/broad/understanding-oriented). Education and being a generalist will reap large rewards, long term. So stick with it and take that class. Assembly is a very important foundation class that educates you, long-term....
Another rhetorical question I have is this: "Are you passionate for IT or is it just a high-paying (presumably) job?" If it isn't a passion of yours, find you passion and do it well. If it is, take Assembly and like it -- it'll help you appreciate IT, your computer, your high-level language, and give you a more educated view of the "soul" of your computer.
(They don't make you take Assembly at many/most schools for their health. It would be a crying shame to remove it from the required courses).
Re:YES! (Score:3, Insightful)
Many different ways.
Using an emulator of a legacy machine would be one way. You could also use evaluation kits for various microcontrollers ('51, ARM, PIC, AVR, whatever suits you best). They have the added bonus that you're running on actual hardware. You could also try a processor simulator, which comes with many uC/DSP development kits.
Say I would learn 68000 Assembler, would that knowledge be much useful when switching to x86?
Yes, because you have already mastered the concepts behind assembly (registers, processor flags, pointers, etc). A different processor may have different rules, but the concepts stay the same. Some of the rules are the same on many architectures ("If the processor has a zero flag, then counting down in loops is preferable to counting up.", for example). Mnemonics and Opcodes are something you just look up in the documentation.
Re:Yes. (Score:2, Insightful)
Re:Would you trust these professionals? (Score:2, Insightful)
Anyway, the real question/headline should be "Is Assembly Programming Still Relevant to Mainstream Developers, Today?" and the answer is simply no. Because that analogy would be something more like:
Should an elementary school teacher have an MBA so that she can understand the inner-workings of the business environment of her school system in order to be able to more cost effectively teach her students in a manner that maximizes her usage of government funding?
You made some other good points, but I'm just too lazy to comment on those.
Re:Would you trust these professionals? (Score:3, Insightful)
Asking why study Assembler is a little like asking "why study Latin." It's important to have an understanding of the low level programming because it will help you understand what's going on when using something higher level like malloc(), which will in turn help you write better programs.
Just my $.02
Re:All's quiet (Score:1, Insightful)
In my current job I spend the majority of my time looking at stress failures (either crash dumps or live remotes), some of which were on production servers running optimized builds. In order to effectively debug these kinds of failures you really need to understand the following:
Ok so I guess some of isn't directly related to assembly, but it is in the same spirit other people have pointed out which is to know how things work under the hood.
Re:Yes. (Score:1, Insightful)
Re:Yes. (Score:2, Insightful)
Make it right.
Make it fast.
Or,
The rules of optimization:
Rule 1: Don't do it.
Rule 2 (only for experts): Don't do it (yet).
Re:You should not learn it.. (Score:2, Insightful)
If you understand what the gate does, there is no semantical level to break it down any more. Howver, be aware that it consumes Energy.
> a good understanding of quantum mechanics, as well.
That is not so important.
> Understand all the business supply chains, as well.
Yipp, this indeed is important. Understanding why sometimes a technologically favourable solution is not the best makes you a good engineer. (E.g.: Instead of asking "Could we not transport four video streams more over our ethernet if we use an adapted divx coding with increased buffer size?", it may be better to ask: We need a camera, well tested, avaialble in thousands, weatherproof, from an reliable supplier with a standard protocol, because handling a problem in the firmware of a device which is distributed in hundreds over this large industrial facility will consume time and money.)
> Anything else, is just-- pshaw... Black boxing it.
Yepp. More than one Comapany died in such a way.
Re:Yes. (Score:1, Insightful)
It is naive to compare Assembly coding on a Ti86 to Assembly programming on an x86 processor, or a PowerPC processor. yes, the basics are the same, but there is still a lot more going on and necessary to understand than you seem to be acknowledging (albeit, probably unintentionally).
On the scale of a modern game, it takes 50+ people working simultaneously to release the game within 2-4 years (of course not all of them are programmers), and that's in higher level languages, plus some Assembly for the verious graphic's shaders. When you begin to make games on this scale, it's not always just the fact that they didn't make the game in Assembly that brings out the occasional slow down (just to be clear, there are hand optimized Assembly parts, and a lot of developers will write their code in a high level language, then optimize the resulting Assembly). In most cases, it has nothing to do with the fact that they did not do parts in Assembly, but simply has to do with everything that's going on is simply too much to handle especially with graphics, which ironically probably have the most Assembly hand-made in them across the code base.
If you want to code games in Assembly, then more power to you, but good luck trying to do it in a multithreading environment while trying to get something usable that is worthwhile on a deadline.