Assembly Programmers ?

[n2ize]

Anyone besides me coding/optimizing routines directly in Assembly these days ?

[kl7aj]

Quote[/b] (n2ize @ Dec. 11 2007,09:10)]Anyone besides me coding/optimizing routines directly in Assembly these days ?
Yeah, NL7WO. But he's too busy doing work to show up on QRZ. http://www.qrz.com/iB_html/non-cgi/emoticons/smile.gif

eric

[W4INF]

LDA &FF
INC
END


Well, its been many decades, did 6502 Assembly on a Commodore-64, even though that wasnt the chip in it, thats the code it used. Anyway, been a LONG time.

Did a BASIC for/next to clear the screen and one in Assembly... The BASIC was really slow, the Assembly was almost instant.

With .NET, the CLI now makes the language (high level) that you use of no relevance... Hence VB runs as fast/good as C++, as does C#, etc.. I cant imagine doing Windows programming in Assembly, Id rather eat glass! http://www.qrz.com/iB_html/non-cgi/emoticons/laugh.gif

[KG6YTZ]

Since compiled assembly talks directly to a microprocessor in its own native language, it's as fast and efficient as it can possibly be, but... no, not me. #I tried to learn Z80 assembly on my Timex/Sinclair - I really did - but I just couldn't get the hang of it, and abandoned all hope over twenty years ago. #And that's an old, simple 8-bit CPU. #Modern chips? #Forgetaboutit.

[AE6IP]

I have recently worked on the port of NetBSD to the ARM11 processor family. That entailed a bit of assembly code, but even in embedded systems development assembly's getting rarer.

For any processor of any internal complexity, it's almost always better to implement in well understood languages like C and let the compiler do the optimizing.

This is especially true of hardware with any sort of branch delay, multiple instruction units, or out-of-order execution.

[n2ize]

Quote[/b] (AE6IP @ Dec. 11 2007,23:11)]I have recently worked on the port of NetBSD to the ARM11 processor family. That entailed a bit of assembly code, but even in embedded systems development assembly's getting rarer.

For any processor of any internal complexity, it's almost always better to implement in well understood languages like C and let the compiler do the optimizing.

This is especially true of hardware with any sort of branch delay, multiple instruction units, or out-of-order execution.
Of course you wouldn't want to spend the time doing alot of complex stuff in assembly. But those who understand it seem to write better code in a high level langauge like C then those who don't. It also helps a great deal when trying to debug programs written in langauges like C or even C++. There were little glitches that I was able to understand thanks to an understanding of assembly.

I am not a programmer but I do feel that any programmer worth a damned should have at least a basic working knowledge of assembly on the particular machine upon which he will be programming. This is especially true of those working with langauges like C. At the very least it gives the person a better grasp of such concepts as the architechture of the machine, how registers and memory is organized and utilized, how stack space is utilized and how function calls are made, the translation between assembly code and actual machine code, and many other things. I've seen too many people who learn some Java and a few interpreted scripting langauges yet they barely understand any of these things I mentioned previously and yet they call themselves "programmers".

[k5okc]

I've been programming in assembly for years. I use the Macro Assembler called C.

http://www.qrz.com/iB_html/non-cgi/emoticons/biggrin.gif

[K8ERV]

You are a wimp. Assembly? Try Machine Language, don't need no stinkin assembler pgm.

Tom K8ERV Montrose Co.

[n2ize]

Quote[/b] (K8ERV @ Dec. 12 2007,09:56)]You are a wimp. Assembly? Try Machine Language, don't need no stinkin assembler pgm.

Tom K8ERV Montrose Co.
Actually I've done a little of that in which I've translated assembly instructions directly into machine code. I've also "modified" certain programs by opening the executable directly in a hex editor and modifying the machine instructions directly.

Of course REAL PROGRAMMERS who are worth anything at all use machine code from start to finish. None of this faggy assembler langauge for them !!

[K8ERV]

I used to be able to write about 50 lines/mistake in machine. Programs have gotten a bit larger tho.

Tom K8ERV Montrose Co.

[KG6YTZ]

Quote[/b] (n2ize @ Dec. 12 2007,10:01)]Of course REAL PROGRAMMERS who are worth anything at all use machine code from start to finish. None of this faggy assembler langauge for them !!
C:> COPY CON PROGRAM.EXE_

http://www.qrz.com/iB_html/non-cgi/emoticons/biggrin.gif

[KB3NDN]

Quote[/b] (K8ERV @ Dec. 12 2007,04:56)]You are a wimp. Assembly? Try Machine Language, don't need no stinkin assembler pgm.

Tom K8ERV Montrose Co.
whats the difference? assembly language just uses mnemonics. replace the letters with their binary equivalent and you are machine coding. http://www.qrz.com/iB_html/non-cgi/emoticons/biggrin.gif

[K8ERV]

Big difference, Assembly makes it much easier to not make mistakes, or to correct them. And to read the program. Machine is much more basic (pun intended).

Tom K8ERV Montrose Co

[KG4RUL]

Real programmers program in in CMS2 under Ultra16 on a UYK-7!

[k3msb]

John --

I occassionally use assembly language for optimizing my DSP applications on Texas Instruments (TI) DSPs.

The TI Compiler is pretty darn good (I'm using C++ for my HOL). When that doesn't get me the speed I need, I'll use their Linear Assembler and Intrinsics. That typically gets me where I need to be.

Our BSP software is written all assembly.

73 Mark K3MSB

[WA7KKP]

I used to dabble in 6502 assembler, but with the new 16/32/64 bit processors, it is much like building your house one molecule at a time.

I think most people simply rely on high level languages like C to do the grunt work for them. Hence, we have code bloat.

Gary WA7KKP

[W4INF]

CLI

Thank GOD!

[KA8NCR]

Quote[/b] (n2ize @ Dec. 11 2007,09:10)]Anyone besides me coding/optimizing routines directly in Assembly these days ?
Occasionally, and I mean *very* occasionally, I'll inline assembly into C.

To code in assembly because you can is like stripping down to your underwear, putting a knife in your teeth and going out, stalking, wrestling to the ground and stabbing a deer and calling it "hunting". Coding in assembly and hunting in that fashion I envision as being both very satisfying and very macho when successful, and highly frustrating, foolish and borderline insanity when unsuccessful.

Even then, after the project is over (or the venison is gone), all you're left with are strange stares and lingering "why".

[KC0MIS]

I use Assembly language, but it is on the darn ol' mainframe.

73,
Chuck

[n2ize]

Quote[/b] (KA8NCR @ Dec. 19 2007,11:29)]Quote[/b] (n2ize @ Dec. 11 2007,09:10)]Anyone besides me coding/optimizing routines directly in Assembly these days ?
Occasionally, and I mean *very* occasionally, I'll inline assembly into C.

To code in assembly because you can is like stripping down to your underwear, putting a knife in your teeth and going out, stalking, wrestling to the ground and stabbing a deer and calling it "hunting". Coding in assembly and hunting in that fashion I envision as being both very satisfying and very macho when successful, and highly frustrating, foolish and borderline insanity when unsuccessful.

Even then, after the project is over (or the venison is gone), all you're left with are strange stares and lingering "why".
Coding in assembly is not as easy or "efficient" (in some cases) as coding in a higher level langauge like C. It would be ludicrous for me to code complex functions in assembly when I can do it much more easilly in C or Java, or C++ or Perl, Python, Ruby, or Matlab.

My primary reason for coding in assembly these days is to keep my skills sharp. Learning and using assembly has improved my ability to code in other langauges. I gain a better insight into exactly what is happening behind the scenes when I write functions in C. A far better understanding as to how things are being arranged in memory, how the stack is utilized at any given time, etc. Furthermore, when comes time to do some debugging, whether it be a program that I have written or that someone else has I find the debugging process is a lot less painful with a knowledge of assembly. Case and point, I never fully understood how floating point values were utilized in C and other higher level langauges until I understood them at the assembly level. Although I am not a programmer by profession I do however think it would be wise for anyone who plans to spend a considerable amount of time doing programming to learn some assembly on some platform, preferably the one they use the most.

[KA8NCR]

Quote[/b] (n2ize @ Dec. 19 2007,12:36)]Quote[/b] (KA8NCR @ Dec. 19 2007,11:29)]Quote[/b] (n2ize @ Dec. 11 2007,09:10)]Anyone besides me coding/optimizing routines directly in Assembly these days ?
Occasionally, and I mean *very* occasionally, I'll inline assembly into C.

To code in assembly because you can is like stripping down to your underwear, putting a knife in your teeth and going out, stalking, wrestling to the ground and stabbing a deer and calling it "hunting". Coding in assembly and hunting in that fashion I envision as being both very satisfying and very macho when successful, and highly frustrating, foolish and borderline insanity when unsuccessful.

Even then, after the project is over (or the venison is gone), all you're left with are strange stares and lingering "why".
Coding in assembly is not as easy or "efficient" (in some cases) as coding in a higher level langauge like C. It would be ludicrous for me to code complex functions in assembly when I can do it much more easilly in C or Java, or C++ or Perl, Python, Ruby, or Matlab.

My primary reason for coding in assembly these days is to keep my skills sharp. Learning and using assembly has improved my ability to code in other langauges. I gain a better insight into exactly what is happening behind the scenes when I write functions in C. A far better understanding as to how things are being arranged in memory, how the stack is utilized at any given time, etc. Furthermore, when comes time to do some debugging, whether it be a program that I have written or that someone else has I find the debugging process is a lot less painful with a knowledge of assembly. Case and point, I never fully understood how floating point values were utilized in C and other higher level langauges until I understood them at the assembly level. Although I am not a programmer by profession I do however think it would be wise for anyone who plans to spend a considerable amount of time doing programming to learn some assembly on some platform, preferably the one they use the most.
I was just funin' with you.

I've spent a lot of time the past couple of years hanging around a certain university's Computer Science department; this is still taught and required endurance for undergrad CS degrees. They spring it on them the senior year.

[N3RQ]

Quote[/b] (KG4RUL @ Dec. 14 2007,15:46)]Real programmers program in in CMS2 under Ultra16 on a UYK-7!
You are taking me back to my early days in the field. I used to write code for the UYK-5. The UYK-5 was an octal machine with 16K 18-bit words of ferrite core memory.

[W1GUH]

The title of this thread put me into a cold sweat, followed by uncontrollable anxiety. http://www.qrz.com/iB_html/non-cgi/emoticons/smile.gif

My "baptism by fire" into the software world was to code an advanced algorithm, requiring double precision arithmetic (yes, including multipy and divide), on a 70's era mini-computer, including a 2 dimensional linked-list. Add to that a programming console that, despite it's being around for 20 years, could find new, unexpected "features" to throw at the programmer....well, you get the picture.

The unbelievable attention to detail nearly burnt me out. Luckily, just as I was approaching that point, it started working. Whew!

How much did I long for...

for(i = 0;i < 73;i++)
{
}

or even...
for I in 1..73
loop
end

But...assembly language is the best way to pick up speed where necessary, and for that, bless it's heart and soul!

[K1MDC]

Quote[/b] (WA7KKP @ Dec. 19 2007,05:16)]I think most people simply rely on high level languages like C to do the grunt work for them. Hence, we have code bloat.
I think most programmers use high level languages because they make so many more calls to the OS to provide services than in the old day. OS's are far more amenable and provide a lot more utility than they used to. Making library calls is a lot less confusing using a high level language, believe you me.

With the faster processors and ungodly amounts of memory and storage space on modern computers, code bloat isn't the dirty word it once was. Certainly making poorly performing code is not good, but making a program that isn't optimized for size isn't really that big of a deal.

The only thing I'd use Assembly for is for programming microcontrollers or other embedded systems, and even then, I'd probably just write the bootloaders in assembly and do the rest in C.

[W1GUH]

Quote[/b] (K1MDC @ Jan. 20 2008,21:45)]Quote[/b] (WA7KKP @ Dec. 19 2007,05:16)]I think most people simply rely on high level languages like C to do the grunt work for them. Hence, we have code bloat.
I think most programmers use high level languages because they make so many more calls to the OS to provide services than in the old day. OS's are far more amenable and provide a lot more utility than they used to. Making library calls is a lot less confusing using a high level language, believe you me.

With the faster processors and ungodly amounts of memory and storage space on modern computers, code bloat isn't the dirty word it once was. Certainly making poorly performing code is not good, but making a program that isn't optimized for size isn't really that big of a deal.

The only thing I'd use Assembly for is for programming microcontrollers or other embedded systems, and even then, I'd probably just write the bootloaders in assembly and do the rest in C.
Not to mention coding speed, reliability, and maintainability.

[n2ize]

A while ago I wrote some documentation about 8086 assembly programming focusing predominantly on 32 bit protected mode programming. I added a couple of interesting sections, one in particular was a section on assembly and floating point arithmetic which focuses both on floating point representation (how floating point values are represented in the machine/memory), floating point arithmetic, and floating point instructions in assembly.
I also included a section on multi module programming, function calls and the stack, calling C/C++ library functions via assembly and vice versa, arrays, and even a foray into translation of assembly instructions into machine language op codes, etc.

This was mainly meant to be informal documentation, for my own reference, however it did turn out more complete and informative. I think it can serve dual roles as instructional and reference documentation. I still want to add a few sections, namely a section on memory, interrupts and some general concepts of logic and logic circuits.

Originally written in text, marked up and formatted in LaTeX, and converted into ps, pdf and html formats. It needs to be proofread, redundancies removed, checked for spelling, grammatical, and technical errors. If I can manage the time to do all this I might be inclined to post it on-line.
Or perhaps throw it into the public domain so interested parties can extract, dissect, or expand upon it as they see fit.

Ironically assembly syntax used in the documentations examples is the newer Intel syntax... Id like to write the examples in Unix/AT&T syntax and furnish both as part of the documentation.

[AD5WY]

I still code in assembly occasionally, but only on a legacy DOS machine that I've kept around (also C++ for it, and inline assembly when it suits...).

I own a full version of VC 6, but haven't used it in a LONG while (I would occasionally install WIN98SE on that DOS machine....). Windows compilers are so bloated; and dependant on "quick fixes" for shortcomings, that I've given up trying to keep up with them.

[N3RQ]

I still code in assembly occasionally, but only on a legacy DOS machine that I've kept around (also C++ for it, and inline assembly when it suits...).

I own a full version of VC 6, but haven't used it in a LONG while (I would occasionally install WIN98SE on that DOS machine....). Windows compilers are so bloated; and dependant on "quick fixes" for shortcomings, that I've given up trying to keep up with them.

Have you tried any of CodeGear's (formerly Borland) offerings?