Re-using Hub space after a cog is loaded - example
Cluso99
Posts: 18,069
My 1pinTV driver reuses the hub space as the screen buffer after the cog is loaded. If the screen buffer is larger than the cog space, more space is added to the cog DAT section (at the end) which may also increase past the normal cog maximum of 496 longs (496*4 = 1988 bytes).
See the OBEX Debug_1pinTV or the thread http://forums.parallax.com/showthread.php?p=885731
If the 1pinTV and 1pinKBD were defined in the one module I could use the hub space for the keyboard for any extra screen buffer characters.
This is a good example of re-using hub space. Any video driver could use this method, thereby re-using a large block of hub space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
See the OBEX Debug_1pinTV or the thread http://forums.parallax.com/showthread.php?p=885731
If the 1pinTV and 1pinKBD were defined in the one module I could use the hub space for the keyboard for any extra screen buffer characters.
This is a good example of re-using hub space. Any video driver could use this method, thereby re-using a large block of hub space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Cluso. NICE.
Dr_Acula.
I'm Postulated some time ago (More at once) - Redesigning Propeller tool's binary structure to have possibility to reusing HUB memory as one chunk.
But it was no many people that say it is BIG win.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I've been thinking about this lately. Let me float my concept and see what you think.
The key to a reusable DAT section is it being exclusively code to load into a cog. My idea is to define an extra block (something like DATX). The idea is the DATX block must start with the cog code (org 0) and the first symbol in that block is how it is referenced.
All DATX blockx would be packed and located at the end of HUB ram in the binary with only access to the first symbol in each DATX block accessible from SPIN to use in a cognew.
Just a thought. I've given it passing thought as to how it might be implemented in the compiler, but not much more than that.
All variables in the DATX blocks would be loaded via reference in par or compile time definitions. No accessing the ram from spin prior to cog load.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Why not? I see no reason in forbidding to preset cog variables in their hub RAM location. It's often more convenient to preset calculated values in Spin rather than PASM, because you have e.g. multiplication and division at no extra cost. Isn't packing DATX fragments nothing else but a shift of their base address?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I'm doing the same with the combined SD SPI and XMM driver that hairymnstr wrote. Its cog RAM is re-used as I/O buffer for the SD card access.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
It is. The issue is variable access in the spin in interpreter is based on the relative address inside the object. In the case of a DATX block the object base is disconnected from the address of the DATX block. In addition, you don't know where the DATX block is going to be located ahead of time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Nice starting idea.
BUT fro usable design we need talk more on it - Maybe TALK with Parallax to organize it THAT them can even incorporate same changes in Propeller Tool.
Thanks and Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Well I thought I'd kick the ball off anyway. I don't have a mortgage on wisdom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Dave
Essentially, we are just using the physical hub address using spin. If the cog requires to access this as hub buffers, then you still pass the address of hub using PAR.
What is needed without having to put all the objects DAT codes together manually so it can all be used as buffers (,etc... i.e. a font loaded later from SD or flash), is a way to somehow (compiler directive) put the·DAT codes sequentially by the compiler and not intermingled with spin code. Perhaps a DATX is needed to just put these together because there are cases where·some DAT code cannot be re-used.
Any easy ideas Brad?
BTW I am also using the compiler to create a lot of the TV parameter calculations using the compiler. Look at the way I just get the user to·edit the values of·PAL, ocols and orows at edit time. Then the compiler calculates all the related timing constants, including long constants and immediate constants. The only calculation that must be done online is the FRQA value which depends on CLKFREQ.
We are almost at the stage of loading cogs from flash/SD via a smaller hub buffer. I have plans to do this in SphinxOS by loading a minute cog stub loader into cog $1F0 shaddow space to take zero footprint in cog. My spin/pasm debugger runs in shaddow ram and takes zero cog footprint.
@pullmoll: Yes, a number of people are re-using hub space. My 1-pinTV is a fairly simple program to follow for how to do this and this object is quite·well documented now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
It would better to not demand any specific cogs for anything.
...And yes guys, I know there are some I/O pins better suited to specific cogs. But various loaders are now being built and you do not know how they have preset any cogs and how your code is being called.
It is my aim to modify ZiCog (and others?) to use SphinxOS to preload the I/O drivers so that ZiCog, etc do not need to know whether it is talking to a PC & Terminal program, another prop running a terminal(s) program, or a terminal program on the current prop (e.g. my 1pin TV & Kbd drivers or TV or VGA and PS2 Keyboard drivers). This is extremely close, just not had enough time - I need to move the SphinxOS rendezvous locations from $7FFF as this will be required to point to the lowest hub code used from the top down, so other programs will know where the resident stuff is located.
I would also like the SD driver to stay-resident so we all don't use different SD/fsrw·drivers as we do currently. mpark placed all the code into 3 cogs for Sphinx, but we do not have the luxury of 3 cogs with a lot of programs. This way, we could have the raw SD access and some FAT16/31 basic stuff in 1 cog. Any extras (file access, etc) could be done by another object and used by the end user under the OS.
Does this make sense?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Regarding this being added to the proptool, well there are quite a number of us writing code that simply cannot compile on the Proptool any more due to conditional compilation. On BST we have #define in its various flavours. How about #packcogs and then have keywords after that, eg beginning, end, @nnnn to tell it where to put the code.
Having written compilers, the problem usually is that you don't know where things are going to end up later, and that can be usually be solved by adding more passes through the code. I suppose the question for Brad is whether he has enough control over the compiler to do this, and if so, is the problem solvable?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/7/2010 3:01:01 AM GMT
You appear to have missed "In the case of a DATX block the object base is disconnected from the address of the DATX block. In addition, you don't know where the DATX block is going to be located ahead of time.". I'm saying it may well be very difficult or quite unclean to map the symbols from the relocated DAT block into the compilers symbol table for that object as at object compile time the compiler has no idea where that chunk of data is going to be relocated to.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"
The point I raised with calculating FRQA at runtime using CLKFREQ was a seperate issue. I am doing this because I can release a binary which could be loaded by SphinxOS and the binary does not know of the clkfreq at compile time.
However, the point is that it would be nice to tell the compiler to place certain DAT objects sequentially so we can reuse this space for multiple buffers, etc and their sizes may not match the dat cog code sizes. Another problem is a huborg statement so that we can force certain code to be compiled at a specific hub address.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Which is precisely why I detailed a method for doing it and went into the limitations surrounding that concept.
A spin object has 3 parts.
- The Method Table
- The DAT Section
- The Spin Methods
All addressing inside that neat little package of bits is relative. When you compile the DAT section separately and place it somewhere else in the hub (sandwiched between 4 or 5 other dat sections packed at the end of memory for example) you have a disconnect between the relative addresses in the SPIN object and the DAT section itself.
Why would you want to do that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"
It is reprint of my post from another thread.
Hi Jessica Uelmen (Parallax).
I'm are not "C" lover - BUT if that "PMC" can give us New "Propeller Tools" That can compile both SPIN and Semi "C"-PMC that are very appreciated.
BUT
1. That New "Propeller Tools" need have possibility to Compile DAT-PASM snippets as separate xxx.bin files without HEADER/FOOTER only RAW COG-PASM Program DAT file's.
... To be possible to call from both "C" and "SPIN" as In-line ASSEMBLY to be executed from any COG and only communicate with them by Given HUB-Memory BOX's.
2. To that "Propeller Tools" need have some new directive's In DAT section -COGDATStart, HUBBOXADD=XXXXX, (This area need have possibility to be visible to compiler that it can use that addresses in "C" and "SPIN" but add Code to compiled Program at END of code REUSED after start of program) COGDATEND,
Regards
Christoffer J
Ps. It is that functions in Compiler I want to have.
"HUB-Memory BOX's" - means Mail-Boex betwen Spin programs and COG programs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I can see that would be a problem for Cluso's program that loads bits of cog code off a sd card that might have been compiled earlier. But what about the case where the entire package is being recompiled? Is it possible to recalculate all those relative addresses as the complete binary is being created?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
PUB free_raw(ptr, size) '' Add the "raw" memory block at "ptr" to the free list. The memory block '' must be long-aligned, and size must be a multiple of four. if size < 4 return repeat until not lockset(locknum) word[noparse][[/noparse]ptr][noparse][[/noparse]BLK_SIZE] := size meminsert(ptr) ' Add to the free list lockclr(locknum)A sample of code that could use this would look something like this:
OBJ mem : "cmalloc" DAT buffer long 0[noparse][[/noparse]16] PUB start cognew(@entry, @buffer) waitcnt(8192 + cnt) ' Wait for cog to load mem.free_raw(@entry, @pasm_end - @entry) DAT org entry mov t1, par rdlong param, t1 loop ' *** more PASM cog code *** jmp #loop pasm_end ' Uninitialized data t1 res 1 param res 1After the cog is loaded the·memory·will become·available·for reuse·by calling malloc.· It seems pretty straight-forward.
Dave
The trick may be to put the assembly code in a separate object with a start stub to cognew it, then make sure the entire object gets loaded into high hub memory (via a loadhigh pragma, perhaps). An additional accessor function could provide the ability to poke initial values into the DAT before it gets loaded into the cog, if you want to do it that way. In any event, the start and accessor function(s) would be one-time executes, anyway, and could be safely overwritten. At least, this seems to be the most "Spinnish" way to accomplish the stated goal.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 5/7/2010 4:23:35 PM GMT
bstc can do that now. See the (-c) command line option. You need a public object in your source file (it has to be a valid spin object) but it will spit out only the dat section with no header or footer into a .dat file.
I'm not getting the mailbox between spin and dat, but I need to re-read the threads a bit more to try and grok what you are after.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"
Not only that, but the memory manager consumes more memory itself. Much nicer to have the compiler do it for you and not worry about additional code to juggle bits around.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"
2. To that "Propeller Tools" need have some new directive's In DAT section -COGDATStart, HUBBOXADD=XXXXX, (This area need have possibility to be visible to compiler that it can use that addresses in "C" and "SPIN" but add Code to compiled Program at END of code REUSED after start of program) COGDATEND,
In Program
COGDATStart
HUBBOXADD=XXXXX,xx
> Directive to Compiler for have Start addresses Of Mail-Box(XXXXX) and bytes else LONGS(xx) reserved.
.......
Some PASM CODE
.......
COGDATEND
It was something that I have thinking on. And that Blocks Compiled separate and added at last to .BIN with loading HEADERS and all discarded after successfully loaded COG's.
and reused by Compiled Program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Dave
My requirement's are
There are multiple things we are after, for differing reasons. I don't know the best solutions and I guess each one will have to be dealt with as a seperate piece of the puzzle. It does help to have an understanding of everyone's objectives.
For Dave: Yes I did see your allocation plan. However, at this time I don't see this as being required, at least from my perspective. It just seems to be placing too much overhead on a little processor. The prop (certainly Prop I) is not an intel processor and·I certainly do not want the baggage that windoze has. I just want a small operating system like back in the early days of CPM and DOS. I am not actually talking about emulators here (like ZiCog, etc) - they are a means to an end. We should be able to develop via members on the forum a great little operating system to play with. This is not meant for professional use. Michael Park has done a great job with Sphinx because it can do the basic functions of DIR, REN, COPY, etc. It can also compile code on the Prop. It just needs to be taken to the next stage of SphinxOS, and jointly, rather than fragmenting various OS flavours.
Brad has provided us with a great cross-platform compiler and the extras such as #define. He has an embedded simple terminal and a loader. It makes the whole development process so much simpler than PropTool & PST. And a number of us cannot live without these #defines.
So, to recap. A number of us have been re-using cog space for some time. However, I have just come up against a reason that it needed to be longer than the actual hub space ocupied by a single cog. With the help of the forum, I devised a way to allocate additional hub space with a compiler command. This space is just zero filled (initially just wasted) until required by the buffer because I cannot place DAT cog objects together contiguously unless I combine them into a single object (like combining the cog keyboard DAT and cog TV DAT into a single object).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The DATX idea sounds good, but why limit it to just DAT sections.· Why not reuse the entire object that is used to load a cog.· Once the cog is loaded you don't need the code that initialized the PAR table or issued the cognew, and you don't need its method table.· Of course, you may need another object that talks to the cog after it's loaded, and provides an interface to it.
So what I think·is needed is a section of memory located some number of bytes after the stack that contains all the throw-away objects.· This could include objects that have nothing to do with loading cogs, but run some initialization code.· So the Prop tool just needs to know the desired cog 0 stack size, and which objects to load after the stack.
Dave
Perhaps the eaiser way rather than reusing the hub space is to have the OS load the driver cogs as seperate binaries and allocate simply the buffers required from the top down. Then the OS loader will not permit a binary to run that encroaches on any of the hub ram allocated (top down). Sphinx sort of does this now but only in a fixed way at present as $7FFF long has not been freed for relocation yet in order to have the top of hub stored here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Presumably you would load up things like keyboard and display at startup, so you could change the order and do keyboard first?
Reloading cogs is another matter. This caught me out on an earlier version of the dracblade when I was recycling the uart object code space, and then needed to restart that object for a baud rate change. It certainly simplifies things if cogs are only ever loaded once. But I take it sphinx objects can be loaded and reloaded?
Thinking through the problem of joining together dat sections to make lots of space, and working with the current compilers, the usual code is
object1
spin
dat
object2
spin
dat
etc
variable names are local within objects, so combining them into one big spin file is not as simple as it sounds. But, hypothetically, if all objects all had unique variable names, you could rewrite your code in one single text file
object1 spin
object2 spin
object 1 dat
object 2 dat
and the dat sections ought to come out one after the other?
The problem I see is that objects were never written to be used as part of one big text file. I spent a day trying to get just three objects to work together with no conflicting variable names. If you are going to go to all that effort, may as well spend a tiny bit more time and rewrite objects as Sphinx objects, with the stardard I/O locations at known locations in hub.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
-Phil
But you could also have global variables, and in particular, you could have the variables that you use to link spin code to dat code, even when those bits of code are not contiguous. Then you can put all the dat at the end as a group.
It is a different way of looking at the same problem. From the point of view of the person who writes the compiler, if each block of code has a defined namespace, then a bit of code that starts with #NameSpace1 and has a variable Variable1 can be tracked by the compiler as variable NameSpace1:Variable1 So the compiler can link up bits of spin and dat code that might be at either end of a program. Is this possible?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/8/2010 8:26:31 AM GMT