Can Initialization Segment be Dynamically Overlayed
Bruce Bates
Posts: 3,045
Propeller Gurus -
Ordinarily I'd go back through all the present documentation and attempt to find my own answer for this, as it seems to be a rather simple question. I'm just afraid it would be a waste of time, since the present documentation is so sparse and preliminary so far (just an observation, not a complaint!).
Embedded chip programmers are usually faced with an all-or-nothing proposition in loading their programs even when bootloaders are available, since (as far as I'm aware) no microcontroller or similar device has offered a dynamic link/loader with which to load program segments (post-execution), or to create what many of us have come to know as a "dynamic overlay structure".
Now, with the Propeller we have the ability to use one or more separate COGs for our·programs or systems, to start and stop our own COGs at will, and to have a fair degree of control-yet-autonomy with/within each of the COGs, with the proper programming techniques, and adequate programmer skills.
Often times a program/programmer may be faced with a large amount of "housekeeping"· or one-time initialization, at or near the beginning of a program. This can chew up a·fair amount·of memory or data space, and heretofore we've had to pretty much live with that issue. I suspect this can be overcome with the Propeller, so that we can free this formerly locked memory/data space.
Can a (say) SPIN program (necessarily the first to execute as I understand things), perform these various and necesssary "housekeeping" or initialization chores, and then cause another program (SPIN or assembler) to overlay itself, then·have it·go on with the ordinary course of events, with all 8 cogs (itself + 7 others) now available to it?
TIA
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Ordinarily I'd go back through all the present documentation and attempt to find my own answer for this, as it seems to be a rather simple question. I'm just afraid it would be a waste of time, since the present documentation is so sparse and preliminary so far (just an observation, not a complaint!).
Embedded chip programmers are usually faced with an all-or-nothing proposition in loading their programs even when bootloaders are available, since (as far as I'm aware) no microcontroller or similar device has offered a dynamic link/loader with which to load program segments (post-execution), or to create what many of us have come to know as a "dynamic overlay structure".
Now, with the Propeller we have the ability to use one or more separate COGs for our·programs or systems, to start and stop our own COGs at will, and to have a fair degree of control-yet-autonomy with/within each of the COGs, with the proper programming techniques, and adequate programmer skills.
Often times a program/programmer may be faced with a large amount of "housekeeping"· or one-time initialization, at or near the beginning of a program. This can chew up a·fair amount·of memory or data space, and heretofore we've had to pretty much live with that issue. I suspect this can be overcome with the Propeller, so that we can free this formerly locked memory/data space.
Can a (say) SPIN program (necessarily the first to execute as I understand things), perform these various and necesssary "housekeeping" or initialization chores, and then cause another program (SPIN or assembler) to overlay itself, then·have it·go on with the ordinary course of events, with all 8 cogs (itself + 7 others) now available to it?
TIA
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Comments
As soon as it is up and running, and the Spin program is halted(and the COG it is running on is free), there shouldn't be any problem in pulling in additional assembler programs from additional EEPROMs (or even the default EEPROM if it is bigger than 32KB) and load them into System RAM for later transfer into whichever COG you want.
I'm not certain about where Spin places variables in System RAM, though, so I can't say how to access them after the Spin program has Halted. (I expect someone else will fill in the details pretty soon)
It may also be possible to use Spin to load those Assembler programs into a known location in System RAM and then start COGs executing it.
You just can't dynamically load more Spin code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
Post Edited (Paul Baker) : 4/8/2006 5:55:03 PM GMT
Your query in http://forums.parallax.com/forums/default.aspx?f=25&m=119653 is along the same lines as mine in "COG and Force Run" (http://forums.parallax.com/forums/default.aspx?f=25&m=119323). The Propeller seems to me to have the architecture of a CDC6600 without the central processor. I can imagine dedicating a cog (PPU in the CDC machine) to handling all sorts of different tasks, including finding and loading specific assembly language progframs into other cogs. What we are tlaking about is an operating system, of course, but everyone on the list has been quick to point out that the Propeller is far too small, far too primitive to warrant thinking like this. Being and old fart I know that we did indeed create rather substantial operating systems for computers with about this horsepower -- the CDC SCOPE operating system is a good example.
So we might think about developing an OS for this little thing -- maybe a pico-OS -- consisting of a 2 stage bootstrap loader with a set of cog programs managed by one dedicated to the OS, something along the lines of
1) reset
2) SPIN starts in cog0
3) SPIN loads the bootstrap loader into cog1
4) cog1 loads the asm pico-OS supervisor into cog0 (clobbering SPIN) and then quits
5) supervisor wakes up in cog0, cleans up the memory, loads the OS tables into low memory thereby initializing the system
6) supervisor starts the scheduler/job manager and then sits back to watch the show
7) job scheduler looks somewhere (a memory chip?) for a job stream and processes jobs by loading specific asm programs into various cogs to perform work
8) when a cog program completes it releases its cog and waits for new work
9) a cog program can ask the supervisor to do something for it -- most often to load another CAPs into another cog to complete some task -- by writingg the details of that request into hub memory at specific locations and setting a semphore that the supervisor monitors
10) these programs could be maintenance code, diagnostic code, system performance tuning code, memory management, and various I/O activities, and so forth.
The key in making this work would be keeping the cog asm programs (CAPS) from getting in each other's way. This suggests that the hub (central) memory would need to be managed by the supervisor (perhaps through a CAP), that there would need to be some tables in central memory (what the CDC OS called "central memory resident" tables) to keep track of what was happening and what sort of program states were present in the cogs.
Clearly this is a lot of work. You need to have an orderly OS architecture, the CAPs all have the be very well behaved (remember that hub memory is wide open -- no protection against badly behaved CAPs) and the memory constraints are pretty tight for the CAP code -- but no tighter than was the case for the CDC6600!
But, like the CDC machine, the entire OS is really just a set of CAPs, aplace to put them so they can be called and loaded, and the bootstrap process that gets the supervisor and the CAP loader running in two cogs. Interestingly, the enitre thing is blazingly fast because its all in asm and its easy to imagine the OS being burned into a single PROM.
The requirement for orderly behavior is pretty strong here. In fact you can't really have "user" code running anywhere on the chip. That is to say, all the CAPs would have to conform to specific requirements and use the OS to accomplish all the necessary tasks. But imagine that you were wanting to do a bunch of different things at different times, each simple but together a lot more than a cog or even a whole Propeller could handle? If you had the pico-OS and a couple of dozen CAPs for well thought-out tasks you might be able to put all this work into a small script consisting of a series of CAPs to be run in a particular order --- the script itself being read by one of the CAPs would read and "executed" by asking the supervisor to start up a cog with the particular CAP specified in the script, waiting while that cog finishes its work, then calling for the next one to be done, etc.
Of course a user might want to write his or her own CAP and one can imagine that there would be some CAPs specifically dedicated to helping run and debug such programs. The specification for CAPs might require that they write some status info, for example, that the RT debugger would, say, read and write to an I2C memory chip dedicated to that purpose. System dies? Reload the OS and read out the memory from that chip for an OS trace. Indeed, one can imagine that in some systems you would want one cog running such a process all the time to enable later debugging of faults.
Making this work involves a number of issues, of course, including some subtle things like avoiding deadlocks wherein there are no cogs to perform the work needed to finish a CAP that already loaded and running but these are exactly the sorts of things that one works out using the supervisor and the scheduler CAPs.
I know this is going way out on a limb because we don't even have the device's basic specifications yet. It may not be possible to make a real pico-OS and it is even more likley that it won't be worthwhile. But there was a whole lot of real work done by these old CDC6600's that was based on the architecture I see (albeit indistinctly) inthe Propeller. It remains to be seen whether this is feasible. But making up an OS is also a project that might be interesting and one could exhume a lot oof good ideas about what is needed and how to do it from the oldControl Data documentation.
Apologies if this is off track. Ramblings of an old man.
Richard Cook, Chicago
Paul, "only" is such a strong word!
So the question becomes, "Can we, as Spin/Assembly programmers pull off the same trick?" I would assert that we could, if we understood the memory structure pointed to by coginit so we could duplicate it, and if there were a way to determine the address of a public Spin method. The answer to the former might simply be gotten by asking the right questions of the right people. I'm more pessimistic about the latter, though, as Spin doesn't like it when you say "@Method", where Method is the name of a public method. So there may not be a way to get such an address, short of combing through a memory dump and figuring it out by hand or placing a code marker at the end of the prior method (e.g. long[noparse][[/noparse]$FFFF] := $12345678), scanning for it, and adding a few bytes to reach the correct address.
So, from a practical standpoint, I can't with any certainty disagree with you!
Cheers!
Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10