Need a challenge to learn assembly
Spork Frog
Posts: 212
Hello all!
I am in need of some ideas right now.
Regarding the Propeller, I feel as if I have a pretty good grasp of Spin. Now, I'm looking to move on to assembly. However, tutorials don't really do a lot for me: I tend to learn the most when I come up with an idea and then write a program with nothing but a reference sheet/manual for the language, to try and puzzle it out myself, learning from the experience.
Therefore, I am looking for ideas for a simple to moderate challenge to help myself learn Propeller Assembly. I've already done some stuff with simply flashing an LED in a timed manner, so... ideas, anyone?
I appreciate and look forward to all feedback!
Thanks in advance
Spork
I am in need of some ideas right now.
Regarding the Propeller, I feel as if I have a pretty good grasp of Spin. Now, I'm looking to move on to assembly. However, tutorials don't really do a lot for me: I tend to learn the most when I come up with an idea and then write a program with nothing but a reference sheet/manual for the language, to try and puzzle it out myself, learning from the experience.
Therefore, I am looking for ideas for a simple to moderate challenge to help myself learn Propeller Assembly. I've already done some stuff with simply flashing an LED in a timed manner, so... ideas, anyone?
I appreciate and look forward to all feedback!
Thanks in advance
Spork
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
Try to pass some of your spin code to assembly...you'll sure found some good questions in the way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
Or better, a minimalistic java interpreter.
A graphics processing routine, like rotating a bimap, changing its size.
You can also try for some nice Mandelbrot or Julia fractals.
Did you ever try to do some cube morphing ?, or textured rotating cube (see "Second reality" or "Crystal Dream 2"
try some division of 64 bit numbers
the list goes on
Have fun
First, you may want to know exactly how signed and unsigned instructions behave with the biggest numbers
adds $8000_0000, $8000_0000 wc
result ?, I do not know, I think 0 with carry, there are more examples if you want
Gru
Graham
you could test it also with POD. It is easy to prepare a program for testing. I can help you if you need assistance.
Thomas
As an aside, generally a technical element that makes up part of a PhD (and is not the guts of the PhD itself or commercially sensitive) does not have to be kept secret in fact more often than not you want to publish it. Anyway if you are interested in making it available you might ask your supervisor about it.
Dr Graham [noparse];)[/noparse]
You may also wish to consider applications which can leverage the Propeller's strengths - parallel processing, two flexible counters per cog, and deterministic behaviour.
When it's all said and done, the user defines an array to hold the values reported and passes it to the driver, which then just sits there and does it's thing.
hid = human interface device
Maybe have the connected? array entry be something the driver user defines. That way, you know to check and don't have to worry about auto detection that may or may not be possible.
Some brackets missing in the above example, due to the forum software interpreting them...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Why don't you become a co-author? I have a project intended to introduce non-programmers to assembly first... I needed a challenge too!
As a part of the book... there will be a section on the first computer program by Lady Lovelace (Augusta Byron).
The guts of the program is to generate solutions to y=a(x)+b(x^2)+c(x^3)...
The first step is to generate the values for the n powers of x... which is done by a sum of differences method... which was originally suggested by Newton...and I believe was misunderstood by Babbage.
I put the code for the sum of differences method into Spin and published it to the forum...
You could try your hand at that...and save an old man some time[noparse]:)[/noparse]
Rich
If you try to find roots of an equation as part of your book you will alienate quite a lot of the readers. Many people are great at practical engineering even binary but their algebra may not go beyond V=IR.
Graham
They are everywhere...and a fresh approach might help some of them... how to do it without creating a sense of rebellion against the material is a major challenge... I might leave it out of this and put it into a book of teasers for the more advanced reader. My problem is that I began to build toward it in the intro... using seven bits in an example... which I then link to ADA then to Pascal and finally to Babbage... I'm hoping to spice it up and create some controversy in the reader's brain to keep the reader interested... even if they reject the math and the code.
Rich
I almost finished the pPropellerSim, so I can safely test my code
@rjo_: As Graham said, that could be a difficult problem for most people to (bother to) understand. Some years ago, around 14 or so, I developed a course to teach assembly (x86), the course started from the basics, binary arithmetic, cpu/memory functions. And went introducing instructions in every lesson, addition/subtraction, logical operations, comparison, and so on. And with that to try to build something useful. I heavily used the a86/d86 package, great (and simple) for everyone to test and try learned lessons.
May help
I'd like to look at it. At the time I started... I was targeting a rather small group... heavy on experience, short on time. Then I decided a college student level could probably be worked into it. I didn't really consider all of the people I might turn off by my approach. So, Graham's comment was really helpful.
Rich
Coupla thoughts:
Computer math is it's own entity really. Sure all math is related, but there is a special set of skills required to deal with most computers. In particular, discrete number representations and limited operation sets must be applied to higher math problems. Brute force is not a viable option a high percentage of the time, so problems need to be broken into elements that make sense.
In this, I think the example rjo_ offers is actually a really good one. However it's at too high of a level to serve as an introduction. I'm rapidly getting there, so for me it would be a good read!
Long ago when I first faced this, I struggled with math operations big time. Back then, it was the 6502 and that meant dealing with only 8 bit numbers, add, subtract and power of two shifts for a coarse multiply and divide capability.
At that time, the group of us writing programs used a combination of high level language stuff and assembly code, largely because of the math issues. Was easier to apply concepts one at a time, or at one level at a time.
Eventually, many of us got there and ended up writing some fairly good assembly language programs. Now, for me of course, having set all that aside for too many years, I'm going back through the same process. It's this kind of bizzare knowing it's possible, work and instruction flow concepts coming together nicely, but yet missing lots of little details. --but that's where the fun is, IMHO, so I'm good.
The absolute most valuable things from that time --and those things I find myself re-learning and applying today are:
-powers of 2
Know the first 16 of these cold, more if you can, but the first 16 powers of two are just totally handy everywhere all the time. Adding these together is a close second. This all just pops up everywhere.
-computer math notation and representation
Binary, octal, HEXadecimal are the corner stones of assembly and also need to be known cold. Thinking in terms of $FF or 255, etc... needs to be quick and easy to visualize. There is so much about computers that ties directly to these representations I don't even know where to start, only that it's just critical to do so. Of these, one could skip octal, I suppose. I don't find myself using it all that much --never did.
-core operators
At their core computers really only add numbers together and copy them around. That's really it. Everything else comes from that. So, understanding the core math representations --those things you find in your typical bargain bucket calculator is really your math base. From there, it then becomes possible to do higher level things, but only after these things are just rock solid.
Really, this is true for ordinary non-computer math as well.
So it's shift left, shift right, add, add with carry, rotate, compare (subtract), etc...
-two's compliment, and complimenting numbers in general is huge too
The modulo concept, wraparound, whatever you call it is fundamental and quite powerful when combined with the bit operators.
$ff + $01 = $00
$05 - $01 = $04 (no brainer)
$05 + $ff = $04 (compliment --and very important to understand)
Really what happens here is the result is actually $104, but let's say the byte being operated on is discrete. It cannot hold 9 bits, so it wraps around, ignores the carry and the result is really a subtraction. Why this occurs, how you can leverage it, etc... is a critical assembly thing.
-bit operators
AND, OR, NOT, XOR, etc....
Masking bits off, combining results, making decisions, etc... all depend on these things pretty huge. Building representations of things and manupulating those representations is another way to put that.
-comparisons are really subtractions, which really are complementary additions
When we compare two numbers, we are looking for a difference. $00 = the same. Other values indicate greater than or less than and decisions can be made accordingly.
All of this stuff is somewhat CPU specific in that the sizes of things, avaliable op codes, flags, etc... vary, but the core concepts do not. These are the core of computing and are necessary for anyone to really grok assembly computing and see greater success, IMHO.
If it were me, I would start with counters, loops, comparisons, taking input, generating output, and building abstractions with these tools way before I would introduce a solution at the level rjo_ posted. The general idea should be to make the easy stuff easy, thus freeing mindshare for the harder stuff to come. Again, that's where I'm at right now and I know I would have a far worse time of it, having to struggle with these basic things at the same time.
One example I can think of would be to start the TV Text driver, then write assembly programs that display text strings to the screen, or perhaps count a series of numbers. (0 to 9999999) Do the counting in hex, octal and binary, just to reinforce the core tools and firm up abstractions in the students mind.
Really, the representations we make in assembly are highly arbitrary. In the case of the TV driver, numbers are keyed to an index that in turn point to bit patterns that when interpeted by the driver and video generator, result in pixel patterns that form characters we recognize on the screen.
That means being able to verify and visualize those representations, structures, etc... is required also. Knowing to do these things is one problem. Doing them in a way that is correct is another. Doing them efficiently is the third.
So the number counting exercise alone covers a ton of ground, and is highly interactive in that seeing it function poorly is easy because the output is human readable. Same with an LED, making a sound, etc...
Another good one is the same counter, but latched with input somehow. Press a button, it increments. Press another one it decrements, etc...
Checking the result of a higher math computation is not so easy because one either has to have the necessary abstractions in place (library object), or must just examine the raw data somehow and verify it makes sense. Both important skills, particularly the latter, but both also high enough in the chain to require the foundation stuff be obvious, or one risks the amount of learning happening at any one time being to great to do any real good.
Ok, that's probably way more than necessary. Sorry, but I've some passion for these things!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 8/10/2007 2:15:44 AM GMT
@potatohead: That was simply great !
Have fun
Ale
WowThanksWowThanks
I actually have a first pass at some of the keys you listed... but to be able to just spit them out. That's incredible...
now I can just check list it... throw in the jokes and the path opens up pretty nicely.
To everyone else... thoughts?
Thanks,
ILMP (I love my Propeller).
Rich
No... you will make more money by giving it away. I would love it if you and others would make their posts bi-lingual. English is fine... but throw in the Spanish with it. A little Spanish/Russian/German/Chinese/etc never hurt anyone.
Rich
-Better/own graphics driver.
-Single cog keyboard/mouse/gamepad driver. Though I'm not so sure about this one, they require kinda tight timing, all of them... though I suppose if I set both keyboard and mouse to polling mode, it shouldn't be too bad.
-Port my version of John Conway's Game of Life to assembly
A fair list. Should keep me busy for a while.
Possibly you could get a ROUGH idea of your code by looking at SX sasm VP's on this page
Also, I have an HD4470 based 40x4 character LCD that I've been meaning to hitch up for a while, just haven't gotten around to it. (7 bucks off All Electronics. But I'm not convinced it's working...)
So here's the final(?) list:
-Port my version of John Conway's Game of Life to assembly
-40x4 character parallel LCD driver
-Better/own graphics driver.
-Single cog keyboard/mouse/gamepad driver. Though I'm not so sure about this one, they require kinda tight timing, all of them... though I suppose if I set both keyboard and mouse to polling mode, it shouldn't be too bad.
@rjo_: I share your enthusiasm for the Propeller.
Forgot a coupla things: (actually it was just the end of my mid day break --here's the rest of what I planned to write)
-data size notations
bit = single binary digit 0 or 1
nibble = four bits, or half a byte, or one hex digit ($0-$f)
byte = eight bits, two hex digits
word = two bytes
long = 4 bytes = 32 bits.
Knowing the range of numbers these represent is a core thing. Helps with sizing, as in how much memory is required for a particular representation. This discussion is really easy once hex has been introduced. Hex makes it very easy to see / manupulate / think in these terms. This is linked to modulo / wraparound stuff, order of magnitude.
-signed binary and sign extension
For an 8 bit number, you've got bits 0 to 7. The 7th bit can be treated as a sign. That changes the number scale from 0-255 to +127 - 128.
Sign extension is simply making the sign make sense across different data sizes. The upper most bit is always the sign, but math operators might operate on fewer bits. Not so much of a problem on the prop, but still important to understand.
-carry bits
Essentially, one has to capture the overflow when a math operation exceeds the boundaries permitted for a given data type. This is how smaller data elements are chained together to form bigger ones. Core.
-parity
is the number of ones in a given dataset (word, byte, etc...) even or odd? (0 or 1) Lots of implications for this one, so it's just a foundation piece.
-addressing
On the prop, this is an interesting topic. One I'm quite sure I would not give the right treatment. We've got HUB addresses and COG addresses and states to deal with.
-code -vs- data
This is a fun one in assembly! CPU's are really stupid. If their program counter points at something, it's gonna consume it and execute it. So, it's up to the programmer to sort this out. Code can be mixed in with data, data can become code, and the reverse is all true.
Self modifying code comes up here. On the prop, a very worthy discussion. This is likely a subject to come up on a recurring basis.
Inline data, blocks of data, etc... all ripe for small examples.
Cool stuff can happen here. A number is read from the outside world, compared to another number, with an instruction being written somewhere else in the program, depending on the result of the comparison.
The prop does differentiate these somewhat with the COG and HUB. One can consider the COG a programmable CPU, and the HUB the RAM. Of course the reality is more flexible than that, but it's deserving of some serious treatment. COG addressing has some implications here as well, in that everything is just a long. Data, code, does not matter. Just longs that can either do stuff or represent things. The HUB, on the other hand, varies.
-data type alignment
If one masks off either the lower most bit (set to 0) or the two lowermost bits, one ends up with aligned addresses. It's pretty important to understand how that all works, particularly for large model code to come, and for passing pointers to data.
-endian
Little endian -vs- big endian. When working with large or complex numerical representations, or maybe just big integers, one needs to know the order of things in RAM.
Say we are gonna work with a two byte number: $FED7
In RAM, is this:
0000 = $FE
0002 = $D7
or
0000 = $D7
0002 = $FE
This really should be introduced very early on. Lots 'o confusion potential here.
-pointers and indexes
Where is data / passed parameters / flags stored? For arrays and strings, how to index through the string, compare it, etc... terminators. Fixed size, variable sized.
Keep the topic math related, and take somebody through decimal number input, calculation and result output.
Perhaps compare two strings. (and the basis for that comparison is a topic all by itself)
-fixed point binary representation
This is one I could use a refresher on. For an 8 bit number, say you make 4 bits the fractional component, and 4 bits an unsigned whole number component. What does that mean numerically?
Differentiate this from floating point, which is it's own topic.
-integer representation
Given the data size discussion, we've got some nice choices on the Prop. 32 bit numbers are pretty damn big. Lots of stuff can be done with discrete math. This really should be explored with some common examples. Integer math is a huge time saver when the problem fits within the boundaries it allows. Assembly programmers should be looking at this one all the time.
-smart data -vs- compact data (representations)
What do you have more of? Ram, or compute time? How you structure your data representations determines the amount of work required to manipulate them.
I recently worked on an Atari 2600 game. That damn thing only has 128 bytes of RAM! Smart data is a must, meaning one has to work double hard because the machine is a software display driven one. (The prop and that machine are actually quite similar, if one wants to think that way.) So, the gold was smart data that was also fast! (tough)
Totally relevant on the Prop and for embedded stuff in general.
From here, one can get into some good stuff. The higher level math operators make some solid sense. Also, having mastered the core math, binary operators, branching, pointers, etc... one can then explore the many fun options on this chip. Counters, the video generators (serializers), pins, etc...
Some of that stuff can get mixed in, of course. Pins in particular with masking (bit operators), direction, etc are subject for early treatment. aka: blinkin' lights
Edit: One more really obvious one:
-computers count from 0
This one gets me fairly often. We humans think of zero being nothing, but where indexing data is concerned, it's often the "first" element, or iteration through a loop, last iteration, etc...
When one has data, to be manipulated or consumed, an index is required to step through it. (unless one just writes each instruction out, one at a time, but that's no good in a majority of cases, unrolling loops for speed excluded.
So, in RAM we have the string "Hello", and we want to write it to the screen:
$0100 = "h"
$0101 = "e"
$0102 = "l"
$0103 = "l"
$0104 = "o"
Either we know the size of the data, or we delimit it (mark the end of it with something unique).
$0105 = $ff (end of string)
If we want to put this on the screen, we've gotta have a few pointers. One for the start of the screen, one to be added to it that locates the string on the screen, one that points to the data, and one to be added to step through the data. Sure, these pointers, their number, etc... will vary. Not the point however. Setup some pointers, and index them.
The big point, where counting from 0 is concerned is that the index is added to the base data pointer. This is just a core thing, no getting around it. Always trips people up. Happens in higher level languages too, but not so deadly as it is in assembly. In most high level languages, one can just completely ignore this and be consistent about it and have a shot at things working. Just some bytes are wasted. Assembly does not really permit this because of the level we are working at.
If our data pointer is set to $0100, then the index to the first character is then $00. For us humans, we refer to that as the first digit, because we get lots of handy abstractions that do the pointing for us, so using a "1" makes perfect sense.
Not so with the fairly stupid computer. It's gonna just add, or one has to point to the wrong place, then add a 1, which makes zero sense. Indexes are added period. Fact of life.
($0100 + $00 = $0100 = "h")
Same for the screen pointer. Let's say the graphics driver is a character based one. Each byte of the screen represents a pointer to the characters located elsewhere in memory. If this is a 40 x 24 screen, and we want to put "hello" right at the upper left corner, the index would also be $00.
Say the screen is then at $1000. Upper left is $1000 + some offset index for location. It's the concept of the add that is important. Computers only add stuff and copy it around --remember.
If we want to put "hello" 10 characters in, that's beginning of screen (0) + 9 to equal the 10th spot!
$1000 + $09 = $1009 = location for "h"
Now the somewhat confusing part. In the example of the index, we count $00 as actually being something. So "10" really is "9", for the newbie. But that's just for indexes and pointers. Quantities are different things.
Let's say we want to put the word "hello" right below the one we located 10 characters in. That's the second line, which to the computer is actually line number 1. So we multiply 40 chars per line * number of lines -1 to account for the first line being 0, not one as we would expect.
$1000 + ($28 * (2 lines - 1)) + $09 = $1031 = location for "h" (with $28 being decimal 40)
The take away is that we need to differentiate quantities from indexes. So, 40 bytes per line actually *is* 40 bytes per line, not 39! This is true even though said bytes are numbered 0 - 39 in decimal notation.
That writing values to the screen exercise can illustrate this stuff quickly and easily....
PITA, IMHO.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 8/10/2007 5:31:14 AM GMT
There is only one way of testing that display... remember they have 2 separated controllers, for the upper and lower 2 lines groups.
Spanish, castellano:
Spork, el juego de la vida es fant
Rich