Assembly is confusing...

Vaati · 2009-08-22 11:51

I have had some experience in spin, and would really like to learn assembly so I can add a bomb dropping AI to bomberman...·

Are there some code examples for assembly using the propeller tool?· I can't install Viewport because I don't meet the system requirements for the required Windows programs to run the installer...

At any rate, is there some code examples I can look at and understand what is going on?

Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quit buying all those fixed voltage regulators, and·get an Adjustable Power Supply·for your projects!· Includes an LED testing terminal!

*-NEW-* SD Card Adapter·Now available!· Add extra memory to your next Propeller project with ease!

SRLM · 2009-08-22 14:56

There are two tutorials here: http://forums.parallax.com/showthread.php?p=668559

There are also code examples. Look in the stickies.

IMHO, the first step is to learn how to count in binary and hex. Not just understand, but know.

CounterRotatingProps · 2009-08-22 17:18

Hey Vaati,

maybe this is obvious, but I'd plow through PASM side of the propeller manual - either the book or the on-line pdf. It's actually pretty good, but a bit dense because it's really a reference. It's nice to be able to jump back and forth between the SPIN and PASM statements where they are essentially the same operation - but the examples for one or the other are slightly different, with the PASM going into more low level detail and the SPIN more on the 'why'.

Vaati> Are there some code examples for assembly using the propeller tool?
Yes, in the manual too. It's pretty easy actually (well at least the beginning stuff [noparse]:)[/noparse]

@SRLM - thanks for posting that link --- I'm learning the PASM ropes too ... good thread!

SRLM> ... learn how to count in binary and hex. Not just understand, but know

And when you dream in machine code, you're good to go (maybe to the shrink) <G>

cheers
-H

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

BradC · 2009-08-22 17:25

deSilva's PASM tutorial. Search for it. I'm pretty sure it's in one of the stickys up the top. Read it, do it, understand it and you are good to go.
Assembler is the nuts and bolts. If you can talk to the machine in its native tongue there is no better way to get acquainted.

PASM is a doddle really. If you can understand assembler and the (very simple) theory behind it you will have a very good head start on being a decent programmer (you know, one of those people who is not scared to learn/use something other than BASIC and sees a language as just another tool rather than something to be scared of)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?

CounterRotatingProps · 2009-08-22 17:36

deSilva's PASM tutorial. Search for it.

No need to search for it - it's the link SRLM posted just before my post.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

jazzed · 2009-08-22 17:50

potatohead's tutorial is better for beginners as it goes into things like number systems and other key math items.
The Propeller Tricks & Traps Thread/.pdf is also a good read once you get a handle on the basics.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

localroger · 2009-08-22 18:09

PASM is very simple and easy as assemblers go, but it is an assembler and if you've never programmed at that level before it can be very daunting without a tutorial to help you into the framework. If you've programmed in any other assembler -- x86, 8080, 1802, avr, PIC -- PASM is a snap, although the insistence that you use self modifying code to do indexed addressing is likely to lead to a few WTF moments. Methods of using the conditional tests and result flags get a little strange too because most assemblers aren't rich enough to let every single instruction have such flags. But you can get used to it quick. Maybe a bit too quick...

CounterRotatingProps · 2009-08-23 01:14

> Methods of using the conditional tests and result flags get a little strange too
> because most assemblers aren't rich enough to let every single instruction have such flags.
> But you can get used to it quick. Maybe a bit too quick...

Well said, Localroger.

compaired to those other assemblers, PASMs conditions on so many (nearly all?) instructions is amazing in it's flexibility and potential... and it is a tad bizarre if you forget that something was set earlier... %-)

The more I learn PASM, the more I like it!
- H

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

SRLM · 2009-08-23 03:09

I don't really have a place to post this, and this appeared to be the best spot, so here goes...

I've been learning how to work with the Propeller this past year, and started in on assembly a couple of weeks ago. As could be expected, the documentation is great. But, one thing that I find lacking is teaching how to use the facilities provided on the Propeller. There is a difference between good code and bad code, even though both may compile and run. All the documentation that we have shows how to write code, but leaves it up to the developer to somehow arrive at "good" code. I've finished my first year of CS training at my university, and about half the class time in CS courses was discussing theory such as algorithms and architecture. As the years progress, the code in class will eventually just drop out of sight, and it will be completely theory.

Parallax (or tutorials) should not focus on the syntax. It doesn't really matter how to write code line by line. What matters is what's behind the code. Why and how is the bitwise encode operator used? How do I write good PASM? Perhaps most importantly, how do I utilize the unique Propeller architecture? That last one seems to be a big selling point, but all that anybody does is use it to run different modules of code in no different of a manner than 8 separate PICs or AVRs.

I think there needs to be more theory and less rehashing of the documentation. It's more difficult to write and come up with good examples, but it will last it's readers beyond the extreme novice stage, and perhaps some of the lessons will stay for years.

ericball · 2009-08-23 12:58

SRLM said...
I don't really have a place to post this, and this appeared to be the best spot, so here goes...

I've been learning how to work with the Propeller this past year, and started in on assembly a couple of weeks ago. As could be expected, the documentation is great. But, one thing that I find lacking is teaching how to use the facilities provided on the Propeller. There is a difference between good code and bad code, even though both may compile and run. All the documentation that we have shows how to write code, but leaves it up to the developer to somehow arrive at "good" code. I've finished my first year of CS training at my university, and about half the class time in CS courses was discussing theory such as algorithms and architecture. As the years progress, the code in class will eventually just drop out of sight, and it will be completely theory.

Parallax (or tutorials) should not focus on the syntax. It doesn't really matter how to write code line by line. What matters is what's behind the code. Why and how is the bitwise encode operator used? How do I write good PASM? Perhaps most importantly, how do I utilize the unique Propeller architecture? That last one seems to be a big selling point, but all that anybody does is use it to run different modules of code in no different of a manner than 8 separate PICs or AVRs.

I think there needs to be more theory and less rehashing of the documentation. It's more difficult to write and come up with good examples, but it will last it's readers beyond the extreme novice stage, and perhaps some of the lessons will stay for years.

One of the reasons your CS courses focus on algorithms is they are not limitted to a single programming language.· A bubble sort and a quick sort can be implemented in any language, so algorithms never go out of style (unlike programming languages).· However, you must recognize that each algorithm is based on certain assumptions - i.e. the cost of a comparison versus an exchange and the availability of temporary storage space, which may, or may not be, applicable to a given programming language and processing architecture.

I strongly disagree with you on the focus on syntax.· It is vitally important to me to know that "JMP label" has a completely different meaning from "JMP #label".· Neither is incorrect (and both have their uses), but if I use the first when I meant the second, my code will fail - no matter how perfect the algorithm.· The syntax is an essential building block; and is especially critical for PASM where the assembler will not flag many common errors because they are, in fact, legal constructs.

As for using the unique Propeller architecture, I challenge you to find an existing programming language (other than SPIN) or library which maps to the Propeller's parallel processing facilities.· I've looked, and I couldn't find anything.· Most parallel processing languages & libraries either concentrate on loosely coupled network processing or "parallizable" code - i.e. single stream of execution which performs some tasks in parallel.· Neither of which maps well to the Propeller.· But, instead, you see people using the Propeller as, I believe, it was designed - dedicating a cog to a single purpose (e.g. serial interface, keyboard interface, video output) and then having the cogs interact asynchronously as required.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

Hanno · 2009-08-23 20:50

Vaati,
How come you can't install ViewPort? How can I help?

Ericball,
I hope you'll find that 12Blocks nicely maps onto the Propeller's parallel architecture. It let's the user graphically arrange high level blocks into a worksheet. There are multiple "start" blocks, ie for starting on a mouse click, key click, received token, or received message. By using multiple "start" blocks it becomes really easy to write a program that uses multiple cogs. All of the cog management is handled by 12blocks, so even beginners can write sophisticated multi-core programs that use many objects. More info here: 12blocks.com

Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Download a free trial of ViewPort- the premier visual debugger for the Propeller
Includes full debugger, simulated instruments, fuzzy logic, and OpenCV for computer vision. Now a Parallax Product!

CounterRotatingProps · 2009-08-23 23:23

SRLM,

I think eric's generally right on track with his reply.

ericball said...
... the focus on syntax

eric,

I read SRLM a little differently in context, thinking he meant "Parallax (or tutorials) should not focus on [noparse][[/noparse]ONLY] the syntax" as he wants to get a sense of the 'bigger picture' that determines the use of code in the first place.· But I do agree with you %100 about syntax.

Clearly you have to spell correctly or it doesn't work. Or, as you point out, you get the wrong result.

" This run through my speel chucker rightly, but do nuts make much cents " (Sincere apologies to non-English speakers for that one.)

SRLM said...
·the documentation is great. But, one thing that I find lacking is teaching how to use the facilities provided on the Propeller. There is a difference between good code and bad code, even though both may compile and run. All the documentation that we have shows how to write code, but leaves it up to the developer to somehow arrive at "good" code

Yes, that's one of the reasons why I was glad to see Steve and Kuroneco start doing the 'puzzlers'.·

As in learning spoken or written languages, we learn to speak/write better by listening and reading·others who are further along. We are certainly in the right place here for Propeller Wisdom, eh? Yes, we do need 'bigger picture examples' the why more than the how.

Like eric, I've looked at the parallel processing issue (though I'm still a PASM NOOB) having done a fair amount of real-world programming on massively parallel platforms. Eric's right, IMO - the Prop is very special.· Sure, it is like a bunch of AVR's glued together. ... but then again, there's no such critter out there AFAICT - except the XMOS chips (which are also amazing, but have a much steeper learning curve IMO.)

As the years progress, the code in class will eventually just drop out of sight, and it will be completely theory

But in the job world, the theory subsides and the code will fill your plate to overflowing.· Keep those notebooks of algorthms handy though - you'll need them.

I wish I had a snappy reply to the needs of "good coding". It's a skill, and art form - a practiced ability like playing a musical instrument. In fact, in the early days of computers, management learned that music majors and English majors made much better programmers than did the mathematicians and electrical/mechanical engineers. Why? Programming is *composition*.

(There's a legend (myth?) that Boeing figured this out and fired or re-org'ed the mathematicians and engineers from computer programming - and hired music and English grads for cheaper - and got better results... anyone know if that's really true?)

- H

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

ericball · 2009-08-24 00:15

@Hanno - naturally 12blocks maps well to the Propeller since you created it for the Propeller. But that doesn't mean it's not a great programming framework. In fact, I think it looks like a great easy to learn & use language in the spirit of Logo and I'm looking forward to using it to teach my son some programming.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

Vaati · 2009-08-24 14:12

Hanno,

It's not your fault--Viewport requires the Windows installer 2 or 3, which I don't have. When I try to install the required installer, it says I need the .NET Framework 2.0....
After downloading and running *that* installer, it says "Windows 2000 service pack 3 or higher is required." Since I have Win 2k SP2 on this particular laptop on which 99% of my propeller stuff is, I cannot install it...

I suppose I will try it on my other laptops and desktop...

Also, thanks for everyone's responses. I will be sure to read all of the suggested materials.

One final note--does ASM take up less space than spin for the same effect, i.e.; blinking an LED?

Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quit buying all those fixed voltage regulators, and·get an Adjustable Power Supply·for your projects!· Includes an LED testing terminal!

*-NEW-* SD Card Adapter·Now available!· Add extra memory to your next Propeller project with ease!

hover1 · 2009-08-24 14:18

Service Pack 3 is still available for download:
http://download.cnet.com/Windows-2000-Service-Pack-3-SP3/3000-2098_4-10046846.html

Vaati said...
Hanno,

·"Windows 2000 service pack 3 or higher is required." Since I have Win 2k SP2 on this particular laptop on which 99% of my propeller stuff is, I cannot install it...

Thanks.

BradC · 2009-08-24 14:43

Vaati said...

One final note--does ASM take up less space than spin for the same effect, i.e.; blinking an LED?

Generally No. Each PASM instruction takes 1 long. SPIN Bytecode is generally more compact, although quite a lot slower.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?

potatohead · 2009-08-24 15:01

Hanno: Your 12 blocks is excellent, and Eric's reference to LOGO is about right. Perfect for a kid. Man, when we were young --or when we first experienced computing, just being able to type stuff in and have the machine do stuff got it done. A propeller is a lot like that with SPIN.

Vaati: My tutorial has been referenced here. It's a bit wordy, but it does go from nearly the very beginning. One program, that will toggle a pin (your led blinker) is documented to the hilt! There is a perspective, or maybe just a mental mindset that really works well for assembly language programming. I tried to put enough of that in there to spark it in others. If you want to, you can read the thing and think about it for a while. Recommended actually. Another forum member here showed me the value of that. (thanks, BTW! )

It helps considerably to see the pieces all come together in your mind before doing any assembly language. That way, you can stay focused on the bigger picture while sorting out the instructions. Again, the simple LED blink by toggling a pin is presented with enough detail that you will be able to do that.

I tend to get lost in a detail, solve it, look up and say: "Where do I go from here?" At that point (which is where I'm at after a weekend of propeller video coding, interestingly) it's time to just think on the project goal until the instructions make some sense, in context. What I find is the subtext: "Where can I go, and why should I?".

The nice thing about having something like an led blinker to start with, is you can try lots of things without a big investment in having other pieces come together. Loops, counting, some math, bit operations (if you've got a batch of LED's wired up maybe --or the demo board where there are 8 of them on the VGA lines), basic I/O, etc... all can be done on the LED.

Some sample programs for having worked on the beginner one:

LED stays on for 10 seconds, off for 5, on for 10.

On button press down, light LED, on button release wait 5 sec, then LED goes out.

Blink your name in morse code.

Those are the kinds of tasks that you should be able to think through after the beginner tutorial. All of those are perfect think exercizes where you can take the body of stuff you know and literally sequence the tasks you visualize needing to happen, then map them to instructions. From there, put some code in the propeller tool, and start running it.

From there, you will be able to read others ASM and start to tweak things and pick up De-Silvas excellent follow on. The two of us, at the time, wrote so that would work.

Keep your initial expectations low and master the basics. Addressing in COG -vs- HUB, COG registers, the pound sign '#' octothorpe, loops, bit operators, math. Every time I struggle, I go back and find one of the basics isn't quite right. I'm not a pro on this stuff, so that is to be expected. Fix that, think about the project, then continue with good results.

SPIN can take less space to get things done actually. IMHO, the LED blinker is a similar size. Number of lines is close enough to not be a worry. SPIN instructions go a byte at a time. PASM instructions go a long at a time.

@Eric, SRLM, CounterRotatingProps, agreed as my experience plays out your comments perfectly. Propeller is a great chip to learn on, because it is very different. The SPIN + PASM combination suits it perfectly and there really isn't a good match elsewhere. For me, that's a very fun, powerful and entertaining combination.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

Hanno · 2009-08-25 06:51

Vaati,
Sorry about all the hassles required to install ViewPort on your machine. However, sounds like you're just one service pack away- so give it a go!

I'm also a big fan of LED programs- that's the first thing I did with 12blocks. See the video I posted in my upene thread - in addition to potatohead's challenges, here are some more which I did with 12 blocks:
- blink 3 led's, each using a different paradigm- wait/toggle, frequency output, pwm
- blink an led at slow and very fast rates- up to several mhz
- instead of blinking, drive the led with pulse width modulation to gradually brighten an led over several seconds
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Download a free trial of ViewPort- the premier visual debugger for the Propeller
Includes full debugger, simulated instruments, fuzzy logic, and OpenCV for computer vision. Now a Parallax Product!

Agent420 · 2009-08-25 12:11

ericball said...

As for using the unique Propeller architecture, I challenge you to find an existing programming language (other than SPIN) or library which maps to the Propeller's parallel processing facilities.· I've looked, and I couldn't find anything.· Most parallel processing languages & libraries either concentrate on loosely coupled network processing or "parallizable" code - i.e. single stream of execution which performs some tasks in parallel.· Neither of which maps well to the Propeller.· But, instead, you see people using the Propeller as, I believe, it was designed - dedicating a cog to a single purpose (e.g. serial interface, keyboard interface, video output) and then having the cogs interact asynchronously as required.

I think the parallel processing attributes of the Propeller are one of the biggest overhyped and least understood elements of it's architecture.·· Nearly everybody who proclaims themselves a Propeller proponent seems to mention parallel processing, yet really there are very few examples of true parallel processing for a single task...· the multi cog video drivers are the only ones I've seen so far.· These other examples of dedicating cogs to multiple single purposes are really not far removed from a conventional interrupt or on-board hardware system like the pic or avr.

Efficiently using parallel processing has so far been more an issue of software than of hardware, and really that hasn't changed much.· But I think the issue here (as has been inferred in some posts) is that understanding the ideology of how to create a task or algorithm is just as important than how to apply it.

edit -

The most unfortunate aspect of Spin is it's speed, making assembler necessary for most time critical or process heavy applications.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Post Edited (Agent420) : 8/25/2009 12:38:52 PM GMT

Wurlitzer · 2009-08-25 12:42

Agent420 said...
l said...

I think the parallel processing attributes of the Propeller are one of the biggest overhyped and least understood elements of it's architecture. Nearly everybody who proclaims themselves a Propeller proponent seems to mention parallel processing, yet really there are very few examples of true parallel processing for a single task... the multi cog video drivers are the only ones I've seen so far. These other examples of dedicating cogs to multiple single purposes are really not far removed from a conventional interrupt or on-board hardware system like the pic or avr.

E.

Well you obviously have not looked at everyone’s application and parallel processing is a big deal.

I have an application which scans 400 + inputs, looks for a serial input, combines those 2 elements and outputs a dual stream of serial data plus services a VB application running in on a PC, stores input/timing information, handles an almost unlimited group of preset information by reading data from a PC via another com link.

One of the high speed serial outputs drives a 2nd prop chip which is the heart of a driver system which controls 1280 outputs using only 40 additional 32 bit S/R with open collector output ICs. Not bad control using only 2 props and extensive parallel processing in assembly.

All of this is speed sensitive and without parallel processing it would be impossible without GHz processing speed not available in a < $10 microcontroller.

Interrupts are a crutch that can break a time sensitive application. With parallel processing I can be assured of processing time as almost everything was written in assembly.

Regarding the original question on assembly, there are only a relatively few commands to remember and combining those few commands with selectable flag settings and the ability to self modify the code, I find this chip one of the most useful micros to come down the pike in years. Because you may not see or understand a true parallel application does not mean they do not exist.

Agent420 · 2009-08-25 13:10

^ I am not suggesting that parallel processing is not useful, only that examples such as yours seem to be the exception rather than the rule.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

jazzed · 2009-08-25 18:10

It's there if you need it; you just need to use your imagination and unique attributes of the hardware for which you may not have enough experience. Increasing sample rates on IO pins and output rates are good example that I use. IO periods as low as 12.5ns are possible with 4 COGs at 80MHz. I have another application that multiplies the effective amount of COG memory available for a problem by using N COGs and employs other COGs for performing user specified activity all in parallel.

I was disappointed when I found out my Propeller couldn't do things the like Cavium Octeon could do, but the Octeon is of course a serious general purpose 16 core CPU with full SMP Linux support (with all multiprocessor debug available out of the box), fully cache coherent interrupt and hardware accelerator capability, having two 10Gbps channels, and with ability to download a second identical device for double power ... among other things [noparse]:)[/noparse] But the system cost a ton and was too big to fit in an Altoids tin.

Rather than worrying about hype or whatever, perhaps you should focus on the realities before you and use them to your advantage.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Propeller Tools

Jay Kickliter · 2009-08-26 00:04

Here's a post from when I first learned PASM, or assembly for that matter.

http://forums.parallax.com/showthread.php?p=779680

Actually typing in the 1's and 0's really helps to understand what is going on behind the scenes.

Jay

ericball · 2009-09-01 20:36

Agent420 said...

I think the parallel processing attributes of the Propeller are one of the biggest overhyped and least understood elements of it's architecture.·· Nearly everybody who proclaims themselves a Propeller proponent seems to mention parallel processing, yet really there are very few examples of true parallel processing for a single task...· the multi cog video drivers are the only ones I've seen so far.· These other examples of dedicating cogs to multiple single purposes are really not far removed from a conventional interrupt or on-board hardware system like the pic or avr.

Efficiently using parallel processing has so far been more an issue of software than of hardware, and really that hasn't changed much.· But I think the issue here (as has been inferred in some posts) is that understanding the ideology of how to create a task or algorithm is just as important than how to apply it.

I guess the question is "what is parallel processing"?· Because of the long latency to load a cog, the Propeller isn't suited for many traditional "parallel execution of a single task" algorithms.· Instead, it's much better handling "multiple task" scenarios.· And yes, many of those scenarios can be handled by a traditional processor via interrupts or dedicated hardware.· But, with the Propeller you can get the same effect (multiple tasks executing simultaneously) without the contention problems caused by interrupts and the inflexibility of dedicated hardware.
On the other hand, my Composite NTSC sprite driver uses 2-5 cogs in parallel to perform a single task, does that count?· While one cog is generating a line of video, the other cogs are internally rendering a line of video based upon a shared sprite table.· The newer versions of FRSW perform read ahead & write behind logic for SD card access to minimize delays to the other tasks.

Agent420 said...
The most unfortunate aspect of Spin is it's speed, making assembler necessary for most time critical or process heavy applications.

'tis the nature of an interpreted language - memory efficient but slow.· I remember running my first ASM program on the TRS-80 CoCo and thinking "Wow, that's fast!".· Unfortunately, the architecture of the Propeller limits compiled languages to using LMM-style code for anything more than trivial routines.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

Agent420 · 2009-09-02 10:34

^ I'm working on some video driver sprites as well ;-)· I'll agree that things like that are execellent examples of parallel processing, and it's certainly a nice feature and allows you to do things not otherwise possible using a single core at the same speed.· My point was really along the lines that not every task you need to perform is readily applied to parallel processing.· So I'll concede on that topic.

As for pasm being confusing, I think there are some Prop specific elements that makes that true, especially when viewed from the perspective of 8bit cores like the 6502, Z80, avr, pic etc that many people may have previously used...· The lack (or technically combining I guess) of registers like accumulator, x,y &·z etc·is a whole different ballgame, especially when doing things like indexed references and loops.· Self modifying code certainly has been used in the past, but it seems more necessary with pasm to accomplish many conventional tasks.

I find the RES and ORG directives a bit confusing to get used to.· It seems I have to put more thought on where the code is located.· Most compilers provide a summary of variable and symbol addresses, but we don't get that in pasm.· For that matter, because pasm is originally declared in a spin object, I'm not sure really how big the actual pasm code block is - do I have enough room?· Can I fit more buffers?

Other processors have used conditional execution, and the Propeller puts that feature to good use.· I'm still trying to figure out the best way to apply that feature because it seems that if you use more than 2 conditional instructions in sequence you may be better off using a branch or jump because the non-executed instructions run as nops and 2 x nop = 8 cycles = TJZ (no jump).

So for me, part of the confusion is pasm itself and part is the way it is compiled.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

ericball · 2009-09-02 13:21

Agent420 said...
^ I'm working on some video driver sprites as well ;-)· I'll agree that things like that are execellent examples of parallel processing, and it's certainly a nice feature and allows you to do things not otherwise possible using a single core at the same speed.· My point was really along the lines that not every task you need to perform is readily applied to parallel processing.· So I'll concede on that topic.

As for pasm being confusing, I think there are some Prop specific elements that makes that true, especially when viewed from the perspective of 8bit cores like the 6502, Z80, avr, pic etc that many people may have previously used...· The lack (or technically combining I guess) of registers like accumulator, x,y &·z etc·is a whole different ballgame, especially when doing things like indexed references and loops.· Self modifying code certainly has been used in the past, but it seems more necessary with pasm to accomplish many conventional tasks.

I find the RES and ORG directives a bit confusing to get used to.· It seems I have to put more thought on where the code is located.· Most compilers provide a summary of variable and symbol addresses, but we don't get that in pasm.· For that matter, because pasm is originally declared in a spin object, I'm not sure really how big the actual pasm code block is - do I have enough room?· Can I fit more buffers?

Other processors have used conditional execution, and the Propeller puts that feature to good use.· I'm still trying to figure out the best way to apply that feature because it seems that if you use more than 2 conditional instructions in sequence you may be better off using a branch or jump because the non-executed instructions run as nops and 2 x nop = 8 cycles = TJZ (no jump).

So for me, part of the confusion is pasm itself and part is the way it is compiled.

I agree that the code == data == register equivalence takes a little time to wrap your head around.· The closest I've seen in the past is the 8051, which has an accumulator but then uses zero page RAM as a set of registers.· The need to use self modifying also takes a little getting used to, especially since you can't use a single index register across multiple instructions.

ORG and RES are easier to understand when you think of what the Prop Tool is doing.· The Prop Tool has two address counters - one for the current HUB address and one for the current COG address.· Each PASM instruction increments the HUB counter by 4 and the COG counter by 1.· ORG sets the COG counter (typically to 0) while RES increments the COG counter without changing the HUB counter.· Once you have compiled, you can see the addresses for each label in the Prop Tool.· FIT can be used to flag if you've run out of space.

The value of conditional execution is deterministic timing, so it doesn't matter which branch is taken - both require the same number of cycles.· Yes, in some cases it will make more sense to split the branches using IF_cond JMP # (4 cycles), but then it becomes more difficult to keep the timing of both branches the same.· (You also need 2 more longs for the JMPs.)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

Agent420 · 2009-09-02 13:35

ericball said...
Once you have compiled, you can see the addresses for each label in the Prop Tool.· FIT can be used to flag if you've run out of space.

Perhaps I am being a bit thick, but could you tell me how to see the label and symbol addresses?· After compiling, I can see the reported space used, but no mention of addresses.

Object "vga_1024x768_tile_driver_Test" Interface:
PUB  start(base_pin, array_ptr, color_ptr, cursor_ptr, sync_ptr, mode) : okay
PUB  stop
Program:     263 Longs
Variable:     12 Longs

And while I see how FIT can help identify if a program is too large, how would I determine how much more available space I have when the DAT pasm code is loaded into a cog?· That kind of thing would be useful for planning whether I can put data in the cog vs having to place it in main memory space.

In the compiler report above, I'm guessing that information relates to the Spin object that contains my pasm code in it's DAT block, not the pasm code itself?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

jazzed · 2009-09-02 14:28

If your Spin file compiles, click on one of your DAT labels and watch the status bar at the bottom of the window ... it will blink yellow and give you label location and DAT size. That is also good for finding out how many bytes a method takes or what the value of a constant is in the CON section. Nice feature.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Propeller Tools

Agent420 · 2009-09-02 14:33

I didn't even know it did that ;-)· Thanks for the tip!

Would be nice to have that information summarized in report format like it does with the code space.

So would a fair estimate of used cog space be the DAT size (reported in bytes) / 4 ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Post Edited (Agent420) : 9/2/2009 2:41:57 PM GMT

Ale · 2009-09-02 14:44

If that little info is useful just check the listing produced by BST or homespun! for some jaw-dropping awesomeness

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

Agent420 · 2009-09-02 15:05

> If that little info is useful just check the listing produced by BST or homespun! for some jaw-dropping awesomeness

* drops jaw *

Thanks!· I plan on eventually trying out many of these submitted tools, but hadn't got as far as BST yet...· THAT is exactly what I'm used to and what I was looking for from the Prop compiler.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Assembly is confusing...

Comments