Assembler Addressing a MainRam Location
pjv
Posts: 1,903
Hi All;
OK, I must be dense or something, but I have browsed all the tutorials (daSilva's on assembler is very good, but rather short) and documentation, but it escapes me how to·get the assembler·to provide the·address of a main memory (variable) location to a cog-launched cog.
I am aware I can pass this in the PAR register (but I have other needs for that), but how to get the assembler to pass the location to a cog-launched cog is eluding me.
There are lots of docs for SPIN (which is waaaaaay too slow for my purposes), but assembler "how to" I have found precious little.
Why am I not finding that, or is it non-existent? Can anyone point me in the right direction or illustrate the procedure?
Cheers,
Peter (pjv)
OK, I must be dense or something, but I have browsed all the tutorials (daSilva's on assembler is very good, but rather short) and documentation, but it escapes me how to·get the assembler·to provide the·address of a main memory (variable) location to a cog-launched cog.
I am aware I can pass this in the PAR register (but I have other needs for that), but how to get the assembler to pass the location to a cog-launched cog is eluding me.
There are lots of docs for SPIN (which is waaaaaay too slow for my purposes), but assembler "how to" I have found precious little.
Why am I not finding that, or is it non-existent? Can anyone point me in the right direction or illustrate the procedure?
Cheers,
Peter (pjv)
Comments
Look at the manual for the PASM version of coginit COGINIT
Basically you have to make a LONG in the launching cog that tells the cog you are launching where in hub to find the code to load, and the value of PAR passed to the cog you are launching. P284&285 in the 1.1 version of the manual.
Best,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
Yes, I tried that, and as you say the assembler will not return a value for the address, eventhough it is already set at compile time. Pity; this is a real shortcoming. As one launches assembly cogs from assembly cogs, there is no such concept as loading a parameter, and anyway I need to transfer numerous dispersed values, so a single paramter would not do in any case, as they are not contguous. It would be great if in assembler @@ would return the main address
Sure, it's easy from SPIN, but that is not going to work for me.
I wish the "how to" documentation was much better than it is. The commands themselves are all very well descibed, but in isolation. There is precious little from Parallax about how to do things in an assembler-only environment.
Frustrating! This little chip should be able to do wonders, and in SPIN it is easy as long as you don't ask for too much performance, but there are some serious holes when you want to push the limits with assembler, and with improved documentation that ought to be achievable. As deSilva said, all the documentation effort is geared toward SPIN, while beginner assembler details are lacking.
It's taking an inordinate amount of time to get beyound the very basics.
Cheers,
Peter (pjv)
Which it won't as @@ is a synthesized spin instruction (but you knew that already). What you probably didn't know is the other two PC based SPIN compiler implement @@@ which returns the HUB address of a DAT variable at compile time (which is precisely what you are looking for).
Beware though. @@@ in a SPIN block will compile in the Propeller Tool, however it will not do what you expect it to.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Now, an alternative is to load the hub with the address using spin before you launch the cog. Bear in mind that this is flawed if you use launch multiple cogs with the same code. For an example, see my Overlay Loader code (link to thread in Tools link below). You may also be interested in debuggers... Jazzed's debugger, my ClusoDebugger, Ariba's PASD, or Hanno's ViewPort Debugger (his is not free but it looks fantastic and professional). There are also simulators although I did not have any luck with them - perhaps I did not spend enough time getting them to work.
And BTW, ask on the forum if you have a problem. There are plenty of people only willing to help
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I do believe there is help available on this forum, but somtimes the answers are inconsistent with my direction, so then of not much help. At other times the suggestions are bang-on.
@Brad; I have your bst, but I don't see the hex window... and I thought you said it doesn't have it. Did I misunderstand you? I really use that to examine what the assembler generates, and to debug my code.
So the @@@, where did THAT come from?? I do not recall it from anywhere.
@Cluso99; I am likely to write most of what I do in assembler, so I'm launching cogs not from SPIN, so I believe the preloading is not a likely scenario for me. Now, the debuggers are interesting... I have not got around to those yet. Although I consider myself an accomplished SX programmer, I am but a beginner at the propeller. I started with the Prop over 3 years ago, but abandoned it because was disappointed in SPIN's performance compared to the SX, and I found it (as now) difficult to learn the assembler because of lack of information. However, now with the SX in EOL, I'm again looking at the Prop which appears to have a great future with follow-on product, but I'm relegated to assembler because Spin is too slow for my current needs.
And the scarcity of relevant documentation causes me considerable grief..... head-bashing and ARRRGGGing.
But I do appreciate the help I can get, and I hope you all will bear with me until I get the knowledge I need.
I will see what I can ferret out with the debuggers. Will ViewPort help with assembler??
Cheers,
Peter (pjv)
Now, actually you launch the very first part of the code using spin (take a look at your first PUB which says cognew....), so you could do it there before the first PASM cog is launched.
I had the same problem with documentation when I started on the prop. It is much better now, although finding it is still a problem. There are some PASM articles on the wiki and there is OBC's Cookbook. And look at OBC's Tricks and Traps too! If you cannot find something, ask. There is also a 2 page spin command summary and a 2 page pasm instruction summary (not sure where I found it). Make sure you look at the documents that come with PropTool 1.2.6 (ensure you have the latest as there is a lot of extra documents and objects there).
And if you cannot find something ask. Most likely it has been done before - that was my experience anyway.
Welcome aboard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Open the compiled listing window and have a look there, you will find it *much* more helpful for looking at what the compiler generates as you see each individual long displayed as hex for each individual assembler or memory statement.
You need to open the window, then compile your file. Each time you compile your file the listing is updated/refreshed in real time, so you never need to close it and (thanks to a cool suggestion by Ale) it always stays at about the same place so you can see your code change each time you compile.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
When I downdoaded your compiler, I (quite naturally) pressed the familiar F8 key, and saw just the empty window. NOW I see what happens when doing things your way, and man, that's incredible.... much better than what I was expecting.
Thank you so much for creating this, it should be a GREAT help for an old assembler fogey like myself.
Cheers,
Peter (pjv)
!
Credit where credit is due, mpark did the assembler listing first in homespun. I just imitated it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?