General > General Technical Chat
ASM programming is FASCINATING!
(1/24) > >>
eti:
Okay, so my mind works best at the lowest possible (humanly parseable) level, with regard to machines. I find ASM particular fascinating, although I do also use bash a great deal and enjoy that, but ASM and knowing how the internal machinations of digital machines work, REALLY turns on lightbulbs in my brain.

I'm a lonnnnnnng way off knowing even 5% of what I need to know, but am gradually getting used to PIC ASM, and am now learning by messing around with an Altair 8800 simulator and loading registers by hand, and also referring to as much ASM as I can, no matter what the arch.

I've been looking here also, at 6502: http://www.obelisk.me.uk/6502/reference.html

If anyone would like to comment or advise how best to get a true, firm grasp on ASM, I'm open to suggestions.

Thanks guys and girls.
Brumby:
First, I had to get a handle on what ASM programming was.  I took a guess and found I was right - but TLA's have come far further along than seems necessary (IMO).

My first foray into programming was writing in IBM assember and one of my favourite books was the S/360 Principles of Operations manual.  I did 6 years writing applications software in assembler for one company and then changed jobs to another for my assembler skills.

Yes, it is good fun when you pick up a dump, locate the registers then start reading the instructions directly off the hex.  Debugging can be fun, though, especially when the module you're checking is 7MB ... on a 15x11 printout a couple of inches thick.


My recommendation is to start out finding a development platform (which I'll leave others to suggest) and then try a simple example program and/or get a program that actually does something and change some things to see if you can make it do something different, that is according to your intention.

You will find, however, that there are many routines that you will use over and over, so re-writing them every time will wear you out very quickly.  Having blocks of code you drop in can ease this, but mostly there will be precompiled modules you will just call (DLLs for example).

Also, depending on your development environment, the ability for you to create garbage code is greatly increased.  Having a strict discipline in how you do things will become extremely important.  One example is spaghetti code - all too easy to do in assembler, but great for getting yourself into trouble if you're not careful.  Learn to do structured programming.  It will save you when programs get complex.
MK14:
Turning your question upside down, and inside out.

What exactly do you want your Assembly Language programs (ASM), to do exactly ?
Perhaps in the future, when you know how to do ASM programming well.

Answering that, will lead to potential recommendations of the best processor(s) to go for and/or emulate/simulate.

Then you can go typing away, creating/learning your assembly language, and run it.

Unlike high level languages, it is less easy to move between architectures, so the sooner you know which processor you want to spend significant amounts of time with, the better.
But you can move to different architectures, reasonably easily, but any code you have already written, will no longer work, without fairly major, conversion/rewriting.
Unless, you just want to learn tiny bits of lots of different architectures, and never actual write any significantly long, working programs as such.

Your main choices would be 8 bit. Relatively easy, straight forward, and suitable for small/simple/easy programs, to do simple tasks. Such as counting from 1 to 100, on a seven segment display.

16/32 bit, such as the Motorola 68000 series (relatively obsolete these days, but practicable to program by hand, unlike many later processors, which can be done, but are considerably harder). Better suited to bigger, more complicated programs (although 8 bit could in theory do just about anything), a fair bit faster (often), potentially easier for more complicated tasks.

Desktop PC x86, hardware floating point available, can do very big and complicated programs, you probably already have access to these.

At a guess, maybe Arduino is a good choice. You can get them (clones), relatively cheaply (e.g. £1.50), program them from a PC using USB and freely available IDE's. They are 8 bit (other versions are available as well), tons of information about them on the internet, and they have a fairly straight forward, 8 bit architecture.
There are different versions, which I won't list here, such as the Arduino Uno.
They can easily interface to hardware (pre-built I/O stuff, is cheaply and readily available, such as displays, keyswitch boards, etc), and have a similar instruction set (8 bit), to some of the older generation, 8 bit processors.

You can even mix C code with some ASM, and/or use pre-existing libraries.
T3sl4co1l:
I've gone all the way around the circle, I think; early on I started with QBASIC (because it was accessible, and easy), and some rudimentary x86 ASM (because MS-DOS has DEBUG, and I felt a cryptic mystique around using it).  Later, I moved on to Java and C, but also learned a few other instruction sets (AVR and Z80).  Most recently, I've finally done a complete project, in GCC, incorporating one ASM module (for AVR).  So I've learned GAS' particular syntax, avr-gcc's ABI, etc.

I don't recommend x86 for starting out, but it's certainly accessible, and available... ARM too, especially these days.  Learning on a classic platform, like recommended above, is probably a good idea.  Take some months to learn it, write some algorithms; take a break, come back and do some more.  Learn a new instruction set, and so on.  Repeat until you're comfortable with how most traditional ISAs work.

I... well, what I'd have to say is, I'd like to be able to write C in terms of, these statements compile to those instructions, and so on.  But there are too many layers of abstraction, with too ineffective optimization, for that to be the case, at least on the last (AVR) project.  This is an effective way to approach HDL I think, i.e. that certain combinations of statements (processes) produce certain kinds of registers, gates and so on.  But a compiler like GCC at least doesn't quite allow that sort of writing.  But I can say, I'm fluent in both formats, and would gladly write that way if I could.

(The danger of that type of writing, is the high level code starts to take on structures that bubble up from the underlying hardware; when porting to different hardware, it may require structural changes to the code itself, if not semantically -- as long as the C code is valid, not abusing edge cases, built-ins and such, it should compile correctly on any platform -- but for best optimization results, this can be a concern.)

Heh... I guess what I'm really trying to say is, not so much anything about an ISA, just a whine about how GCC 9 is so bad on AVR, I can't "write for the platform" even if I try. :-DD  The upside to that is -- since I'm not even able to write for the platform (in a usefully optimized way), the code is forced to remain general and should compile, if not well, then at least cromulently, for other platforms. :P

But anyway -- even if you can't "write for the platform" (and, really, you shouldn't strive for it, exactly because of portability), you can always review the assembled output from the compiler, and see how it's turning statements into instructions, and see which expressions and statements have more overhead than others, etc.  It's a good exercise, and being comfortable with the platform's ISA makes debugging so much easier.

Tim
peter-h:
The original Z80 etc CPUs were programmed almost entirely in assembler, partly because memory was short and partly because compilers generated horrible code.

I wrote megabytesof code for these chips in the 1980s and 1990s.

You need to be pretty good - much better than today's "PHP hackers" - and disciplined. But your general productivity won't be anywhere near as good as that of a good C programmer doing the same job.
Navigation
Message Index
Next page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod