Don't forget the variable sorting is also done to guarantee alignment.
Uuugh! This behaviour takes away the concept of data structure from the VAR section but will still work to a point in the DAT section. The first time I realized this was the way it worked, I was so pissed I wanted to throw all my Propeller stuff·in the trash. Further "rationalization" of this deficiency is not necessary [noparse]:)[/noparse]· Thank·God for sedatives.
BradC said...
ooo just a thought..
what about this in the top object?
DAT
long 0[noparse][[/noparse]obj1#_space + obj2#_space + obj3#_space]
??
Yes that works but it requires the user to add it to the top object. It's not that there aren't
workrounds it's just that they aren't convenient for an end-user.
A particular case where this is important is with "zero footprint debugging" which requires the
debugging object to have read-write access to a few longs < $200 in hub memory. There are
a few ways such space can be reserved ( DAT, OBJ object[noparse][[/noparse]N], dummy PRI/PUB ) but it would
be nice if the user didn't have to do anything other than include the debugging object and just
use it.
OBJ
debug[noparse][[/noparse] 4 ] : "TheDebugger"
I quite like that idea. The end-user simply uses debug.SetBreakpoint(...) etc as if there were
only one debugger, they only have to define it correctly. Best yet, the debugger can check
the object link table it was called through and check the definition is right ( there will be four
consecutive links to same object ) and then re-use the longs which aren't actually used by
the end-user.
It only works if the debugger object is included in the top-most object but I can live with that.
It doesn't have to be used there, just defined there. The link table searching can also check
for that as all references will point to the same debugger code.
I'm sure this could also be used for debugging multiple Cogs in parallel but I've not even gone
anywhere near doing that so far.
When I next have the PropTool fired-up I'll try implementing that. Thanks.
Richard (ImageCraft) -- Thanks, that's basically what I am doing.
Stevenmess2004 -- I think I can add a flag to disable VAR sorting.
Hippy -- Do you know why the Spin interpreter cares that the top object is at $0010? I mean, isn't the important thing the address to start executing? Instead of a dummy PUB/PRI, what do you think of a dummy top object?
@Hippy: I believe multiple debugging is simple - the bigger problem is having enough cogs and seperate serial ports (fdx cogs and pins) for the debugger.
I have 3 cogs running the Interpreter (Rom, Ram (basically Chip's) and Ram (mine = Cluso)) in cogs 5, 6, 7.
Each of the Ram Interpreters are in seperate objects and pass their start address in an Init routine and have a Start routine which receives the start address for the Chip and Cluso.
PUB Main( running )
if not running
running := true
atRamInterpreter := RamInterpreter.GetPasmAddr 'get the Pasm start address of the interpreter
atClusoInterpreter := ClusoInterpreter.GetPasmAddr
RamInterpreter.Init(atRamInterpreter,atClusoInterpreter) 'initialise the interpreter's addresses
ClusoInterpreter.Init(atRamInterpreter,atClusoInterpreter)
CogInit( 0, atRamInterpreter, $0004 ) 'restart cog 0 with the working RamInterpreter
repeat 'expect a delay while cog 0 reboots this code!!
'
' ALTERNATIVES:
LaunchDebug 'launch the debugger
' LaunchCompare 'launch the compare & time function
repeat 'never gets here
'
PRI LaunchDebug 'launch the debugger
StartSerial (true) 'display options (with commandset)
' StartDebugger(@PasmCode) 'debug test code below
InitDebugger(atClusoInterpreter) 'debug ClusoInterpreter
CogInit( 7, SmallTest , @priStack7 ) '<---- The ClusoInterpreter (being tested)
WaitCnt( CLKFREQ / 10 + CNT ) '?mS
StartDebugging 'and start debugging
repeat '<=== stop here
'
PUB GetPasmAddr
Result := @ClusoInterpreter
PUB Init (Interpreter1_addr, Interpreter2_addr) 'pass @RamInterpreter1 and @RamInterpreter2 start addresses
k_0000_XXX1 := Interpreter1_addr ^ $0000_F004 'setup hub address of RamInterpreter #1 before loading
k_0000_XXX2 := Interpreter2_addr ^ $0000_F004 'setup hub address of RamInterpreter #2 before loading
vector_base := @vector_table 'copy hub address of vector_table before loading
DAT
' ┌──────────────────────────────────────────────────────────────────────────┐
' │ THIS IS THE TEST VERSION of the ClusoRamInterpreter │
' └──────────────────────────────────────────────────────────────────────────┘
org 0
ClusoInterpreter
Currently the code being debugged and the PASM/Spin debugger (the same debugger with command options because it doesn't care if it's debugging spin or pasm) which resides in the top object. At this time, the code being debugged also resides in the top object. I need to seperate these as it has caused a few bugs with PUB and PRI misdecarations.
Don't forget, if you are running multiple versions of the same test object, the hub ram of the object (first 4 longs) needs to be replaced after the code is loaded into the cog. Otherwise all subsequent loads will be incorrect. The same applies if the debugger has a reboot option which reloads the cog under test.
mpark said...
Hippy -- Do you know why the Spin interpreter cares that the top object is at $0010? I mean, isn't the important thing the address to start executing? Instead of a dummy PUB/PRI, what do you think of a dummy top object?
I'm not sure why it's that way but there's a check in the ROM bootloader code to ensure that
word[noparse][[/noparse]$0006] is always $0010. I guess it's just an extra safety check that the Eeprom image
is valid before executing its code. From Chip's ROM Bootloader source ...
' Launch program in ram
'
launch rdword address,#$0004+2 'if pbase address invalid, shutdown
cmp address,#$0010 wz
if_nz jmp #shutdown
Another update. Version 0.15 fixes a bug and adds a warning (trying to catch when you define data after a RES directive.
This version also has my second attempt at hippy's _SPACE request. It totals up all the CON _SPACE = xxx in all the objects and reserves that many bytes starting at $0010. Actually it builds a dummy top object there, but the effect should be the same. Give it a shot, let me know how it goes.
If this _SPACE thing ever works out, will that obviate the need for the @@@ operator requested by Cluso99?
I was thinking about the _SPACE thing last night.
If several sub objects all declare _SPACE and it gets reserved for them.. how do they know not to place their stuff at the start of it and trample over the data placed there by the other objects?
@mpark: No, the offset still applies. The @@@ or whatever is requesting the compiler to provide the actual address in hub memory, not an offset address.
What code are you using to test the compiler - maybe you might like to share it so I can try it in debuging the Interpreter?
@BradC: The user will have to worry about that. Hippy and I just need a way to guarantee to reserve space in hub below $200 for the debugger. I am sure there will be other usesas well.
@BradC: The user will have to worry about that. Hippy and I just need a way to guarantee to reserve space in hub below $200 for the debugger. I am sure there will be other usesas well.
If the user has to worry about it, then why is it an issue to just have ...
DAT
long 0[noparse][[/noparse]debugger#_SPACE]
... at the start of the top object?
The user already has to declare the object and start it in any case.
I'm just trying to figure out why we need to extend the compiler when we can already guarantee that space with a simple addition to the top object (on top of the already required object declaration and object start) - Particularly as doing it this way retains compatibility with the Parallax Compiler and all those that are likely to keep using the existing PropTool?
BradC said...
I'm just trying to figure out why we need to extend the compiler when we can already guarantee that space with a simple addition to the top object (on top of the already required object declaration and object start) - Particularly as doing it this way retains compatibility with the Parallax Compiler and all those that are likely to keep using the existing PropTool?
There's no "need", but it would make things easier. The same lack of need could be levied at any
proposed enhancement.
Breaking compatibility with PropTool isn't really a problem and it will get broken further still unless
homespun ( and others ) will be artificially constrained to handling only source which the PropTool
can also currently handle.
Hopefully any methods of extending our own tools will be elegant enough that Parallax adopts the
same when they have resources to devote to their own tool improvements. I see the best future
for home-grown tools not as competition for each others but as alternatives. At the moment the
ball's in our court for adding enhancements to the Spin language, but I hope they'll all offer the
same capabilities eventually unless a product is designed for a specific niche.
BradC said...
I was thinking about the _SPACE thing last night.
If several sub objects all declare _SPACE and it gets reserved for them.. how do they know not to place their stuff at the start of it and trample over the data placed there by the other objects?
That's a good question and a problem I recognised when I suggested the idea. Perhaps the best
solution is to have _SPACE and @_SPACE as compiler constants which returns the value and the
address of where that space starts for each object ...
CON
_SPACE = 256
PUB Main | i
repeat i from 0 to _SPACE-1
byte [noparse][[/noparse] @_SPACE + i ] := 0
There's no "need", but it would make things easier. The same lack of need could be levied at any
proposed enhancement.
Breaking compatibility with PropTool isn't really a problem and it will get broken further still unless
homespun ( and others ) will be artificially constrained to handling only source which the PropTool
can also currently handle.
Hopefully any methods of extending our own tools will be elegant enough that Parallax adopts the
same when they have resources to devote to their own tool improvements. I see the best future
for home-grown tools not as competition for each others but as alternatives. At the moment the
ball's in our court for adding enhancements to the Spin language, but I hope they'll all offer the
same capabilities eventually unless a product is designed for a specific niche.
All fair points.
Question. A) How does the object using the reserved _SPACE know where it starts?
(looks like our posts crossed paths)
What if the top object has enough methods and objects to push the _SPACE allocated past $1FF?
(admittedly a far reach, but possible in theory)
@mpark - How have you implemented the _SPACE as a dummy object?
I was thinking if it occupied method 1 in the object table (which is _always_ located in the same position) then it would be a cakewalk to determine where the allocated space actually begins.
That construction not conflict with PropelerTools and have more reliable Reading.
Samt compiler can test and warn if it is conflict betwen 2 in several sub objects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stuipid question there is atleast one inteligent answer If you dont ask you wont know
That's a good question and a problem I recognised when I suggested the idea. Perhaps the best
solution is to have _SPACE and @_SPACE as compiler constants which returns the value and the
address of where that space starts for each object ...
CON
_SPACE = 256
PUB Main | i
repeat i from 0 to _SPACE-1
byte [noparse][[/noparse] @_SPACE + i ] := 0
Hrm.. I don't know how mpark does his object compilation, but I compile all my objects separately, then binary link them in a 2 pass process (write out the bytecode, then adjust the object pointers in the method tables). Both this, and the @@@ idea tend to pose problems as you don't know the value of those addresses at compile time. (A problem generally inherent in having relocatable objects I'd guess). I'd have to think pretty hard about how to include constants in the code in such a way as to be able to adjust them at link time.
I guess I could place 5 $3C opcodes in a row into the binary (which should _never_ otherwise occur) and then replace them with a 4 byte constant at link time. Wasteful of bytecode, but only 2 bytes I guess.
The problem is you are never going to know the addresses at compile time, and you are never going to know the size of a compiled object until you have compiled it.
As to how you would use @@@ in a dat block..
Am I thinking to narrowly? Is there an easy way to do it ?
I think it would be possible to determine @_SPACE at compile time. Keep track of all _SPACE gone so far as each object/sub-object is compiled. As long as the top-object is compiled as a pre-pass it will be known how big the method link table will be. At worse a duplicate object turned into one will have twice as much _SPACE allocated as it needs. I'd say an object with _SPACE shouldn't be considered a duplicate anyway.
Handling @@@ would be a bigger problem.
As to _SPACE going beyond $1FF, I'd not worry about that but allow it. It should be up to the object using it to check @_SPACE < $200 if required. The situation is no worse than a Cog being launched not starting. I wouldn't be adverse to it being a compile error.
The alternative to how it's done now is to compile to an intermediate form ( such as that my bytecode disassembler produces ) at which point it's a single source in traditional 'no object' form and then assemble that. No linking involved as all labels and references will be in the single file.
This single main file could have "#include objectFile.xxx" so each 'compiled object file' can be compared for duplicates and only included once.
If I were writing a Spin compiler I'd do it this way. An advantage is that it's easy to add optimisation stages transparently, for individual objectfile.xxx and the 'everythning included' programfile.xxx - That's why my disassembler produces code in the form it does as one day I hope to write an optimiser and a re-compiler, as well as making it easier for people to write other language compilers producing the intermediate code and not having to worry about assembling and linking the bytecode itself.
All the advantages of late linking / fix-up without the compiler having to worry about keeping track of things.
Something like this wouldn't be a problem to assemble ...
_CLKFREQ LONG 80_000_000
_CLKMODE BYTE XTAL1_PLL16x
Checksum BYTE 0
Header WORD Obj_1
WORD Pub_1_1
WORD Stack
WORD Var
Obj_1 LINK Obj_2
LINK Pub_1_1
LINK Pub_1_2
LINK Obj_2_1
_SPACE_1 LONG 0[noparse][[/noparse]10]
_SPACE_2 LONG 0[noparse][[/noparse]100]
Pub_1_1 PUSH #_SPACE_1
RET
Pub_1_2 RET
Obj_2 LINK Vars
LINK Pub_2_1
Pub_2_1 PUSH #_SPACE_2
RET
Var ...
Stack ...
The alternative to how it's done now is to compile to an intermediate form ( such as that my bytecode disassembler produces ) at which point it's a single source in traditional 'no object' form and then assemble that. No linking involved as all labels and references will be in the single file.
This single main file could have "#include objectFile.xxx" so each 'compiled object file' can be compared for duplicates and only included once.
If I were writing a Spin compiler I'd do it this way. An advantage is that it's easy to add optimisation stages transparently, for individual objectfile.xxx and the 'everythning included' programfile.xxx - That's why my disassembler produces code in the form it does as one day I hope to write an optimiser and a re-compiler, as well as making it easier for people to write other language compilers producing the intermediate code and not having to worry about assembling and linking the bytecode itself.
All the advantages of late linking / fix-up without the compiler having to worry about keeping track of things.
Something like this wouldn't be a problem to assemble ...
Hrm.. novel idea.
I sort of do this already but only on a per method basis. I compile to a sort of intermediate code represented as a chain of tokens I can loop over to optimise addresses prior to final method assembly. Logically if I chained them all together I could simply assemble the entire object in one hit rather than on a method by method basis. Object chaining will require a bit of thought.. but it's certainly doable.
Gotta think about that some more.. it would certainly make @_SPACE and @@@ in Spin code easy. Not sure I want to think about those constants in DAT though. The Assembler is a different kettle of fish. One could very easily use some spin glue to insert them into DAT prior to use though.
Yes, there is a challenge in keeping the code compatible with what Spin does no matter how nice it would be to do it as it should be. For the "long @hubLabel" in DAT that would have to be generated as "long @hubLabel-@objectBase" to keep the offsets the same.
Implementing _SPACE as a dummy first method is what hippy suggested, but I've been trying to avoid thinking about bumping up method numbers (although now that I do think about it a little, it doesn't seem that bad). Mostly I thought a dummy top object would make it easy to figure out where the _SPACE space starts (always $0010) and would give people a little more of that precious <$200 memory.
Unlike my first attempt at _SPACE, this time I at least tried running a program with non-zero _SPACE (and it worked!). But I didn't actually use the memory. I leave that to you kids with your newfangled debuggers and whatnot.
I have the same problem as Brad as far as @@@ not knowing where it is.
Sapieha, are you familiar Spin bytecode? Not just the opcodes, but the way objects are laid out in memory? It seems to me that your ORGXXX suggestion would be very difficult to implement. But maybe I just have to think about it some more.
Sapieha's ORGXXX could work with my idea of a flat assembly language image file. It might need the file re-ordering to get things in ascending sequence but it could be done on-the-fly. I haven't considered the exact implementation details but it should just be a case of if an ORG is less than current location, error, if higher, add some padding.
Ok, I need someone to explain to me the precise purpose of @@@ and where it would be used. I'm just not getting something.
@@ gives you the hub address of a spin or DAT symbol at runtime.. why can't you just use a bit of spin setup code to poke that into a variable in DAT somewhere?
@BradC: Here is a piece of PASM code that needs to know the physical hub address of a variable. However, only the object offset is available and it is necessary to add another offset to it to find the exact hub location.
CON
' The following is the object offset needed to be added to [url=mailto:#@xxxx]#@xxxx[/url] in a DAT block of pasm instructions (compiler restriction)
DB = $10 '<=====
DAT
org 0
Pasm rdlong Cog_var, [url=mailto:#DB+@Hub_var]#DB+@Hub_var[/url] 'get variable from hub (lower $200)
.....
wrlong Cog_var, [url=mailto:#DB+@Hub_var]#DB+@Hub_var[/url] 'put variable into hub (lower $200)
.....
Cog_var long 0-0 'variable in cog
.....
Hub_var long 0-0 'accessed directly in hub (not cog!!!)
It would be cleaner to replace "[url=mailto:DB_@Hub_var]DB_@Hub_var[/url]" with "@@@Hub_var" (or whatever @@@ is replaced with).
@mpark: I may have led you astray. It actually does not matter if the hub ram is in the lower $200 longs. The problem is the same.
The requirement is for the assembler code to address hub ram. There is no mechanism for the assembler code to refer to a label defining hub memory. The current workarounds are as I indicated above, or to have the spin code modify the pasm code while still in hub ram before the cog is loaded. This is why many programs just use a piece of hub ram like $7FFC without reserving it.
@BradC: Because there are lots of times where you require this. It is known by the compiler, just not exposed. And to actually do it correctly (I mean not hardcoding offset to $0010) requires walking the object at runtime which is neither efficient nor intuitive. In my opinion, it is a compiler deficiency - others may not agree, but that's my opinion. The only reason for keeping it the way it is, is if there were separate linkers and relocatable objects, and we are way off from that.
Comments
what about this in the top object?
DAT
long 0[noparse][[/noparse]obj1#_space + obj2#_space + obj3#_space]
??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Yes that works but it requires the user to add it to the top object. It's not that there aren't
workrounds it's just that they aren't convenient for an end-user.
A particular case where this is important is with "zero footprint debugging" which requires the
debugging object to have read-write access to a few longs < $200 in hub memory. There are
a few ways such space can be reserved ( DAT, OBJ object[noparse][[/noparse]N], dummy PRI/PUB ) but it would
be nice if the user didn't have to do anything other than include the debugging object and just
use it.
I quite like that idea. The end-user simply uses debug.SetBreakpoint(...) etc as if there were
only one debugger, they only have to define it correctly. Best yet, the debugger can check
the object link table it was called through and check the definition is right ( there will be four
consecutive links to same object ) and then re-use the longs which aren't actually used by
the end-user.
It only works if the debugger object is included in the top-most object but I can live with that.
It doesn't have to be used there, just defined there. The link table searching can also check
for that as all references will point to the same debugger code.
I'm sure this could also be used for debugging multiple Cogs in parallel but I've not even gone
anywhere near doing that so far.
When I next have the PropTool fired-up I'll try implementing that. Thanks.
Stevenmess2004 -- I think I can add a flag to disable VAR sorting.
Hippy -- Do you know why the Spin interpreter cares that the top object is at $0010? I mean, isn't the important thing the address to start executing? Instead of a dummy PUB/PRI, what do you think of a dummy top object?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
I have 3 cogs running the Interpreter (Rom, Ram (basically Chip's) and Ram (mine = Cluso)) in cogs 5, 6, 7.
Each of the Ram Interpreters are in seperate objects and pass their start address in an Init routine and have a Start routine which receives the start address for the Chip and Cluso.
PUB Main( running ) if not running running := true atRamInterpreter := RamInterpreter.GetPasmAddr 'get the Pasm start address of the interpreter atClusoInterpreter := ClusoInterpreter.GetPasmAddr RamInterpreter.Init(atRamInterpreter,atClusoInterpreter) 'initialise the interpreter's addresses ClusoInterpreter.Init(atRamInterpreter,atClusoInterpreter) CogInit( 0, atRamInterpreter, $0004 ) 'restart cog 0 with the working RamInterpreter repeat 'expect a delay while cog 0 reboots this code!! ' ' ALTERNATIVES: LaunchDebug 'launch the debugger ' LaunchCompare 'launch the compare & time function repeat 'never gets here ' PRI LaunchDebug 'launch the debugger StartSerial (true) 'display options (with commandset) ' StartDebugger(@PasmCode) 'debug test code below InitDebugger(atClusoInterpreter) 'debug ClusoInterpreter CogInit( 7, SmallTest , @priStack7 ) '<---- The ClusoInterpreter (being tested) WaitCnt( CLKFREQ / 10 + CNT ) '?mS StartDebugging 'and start debugging repeat '<=== stop here 'PUB GetPasmAddr Result := @ClusoInterpreter PUB Init (Interpreter1_addr, Interpreter2_addr) 'pass @RamInterpreter1 and @RamInterpreter2 start addresses k_0000_XXX1 := Interpreter1_addr ^ $0000_F004 'setup hub address of RamInterpreter #1 before loading k_0000_XXX2 := Interpreter2_addr ^ $0000_F004 'setup hub address of RamInterpreter #2 before loading vector_base := @vector_table 'copy hub address of vector_table before loading DAT ' ┌──────────────────────────────────────────────────────────────────────────┐ ' │ THIS IS THE TEST VERSION of the ClusoRamInterpreter │ ' └──────────────────────────────────────────────────────────────────────────┘ org 0 ClusoInterpreterCurrently the code being debugged and the PASM/Spin debugger (the same debugger with command options because it doesn't care if it's debugging spin or pasm) which resides in the top object. At this time, the code being debugged also resides in the top object. I need to seperate these as it has caused a few bugs with PUB and PRI misdecarations.
Don't forget, if you are running multiple versions of the same test object, the hub ram of the object (first 4 longs) needs to be replaced after the code is loaded into the cog. Otherwise all subsequent loads will be incorrect. The same applies if the debugger has a reboot option which reloads the cog under test.
I'm not sure why it's that way but there's a check in the ROM bootloader code to ensure that
word[noparse][[/noparse]$0006] is always $0010. I guess it's just an extra safety check that the Eeprom image
is valid before executing its code. From Chip's ROM Bootloader source ...
' Launch program in ram ' launch rdword address,#$0004+2 'if pbase address invalid, shutdown cmp address,#$0010 wz if_nz jmp #shutdown▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
This version also has my second attempt at hippy's _SPACE request. It totals up all the CON _SPACE = xxx in all the objects and reserves that many bytes starting at $0010. Actually it builds a dummy top object there, but the effect should be the same. Give it a shot, let me know how it goes.
If this _SPACE thing ever works out, will that obviate the need for the @@@ operator requested by Cluso99?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
If several sub objects all declare _SPACE and it gets reserved for them.. how do they know not to place their stuff at the start of it and trample over the data placed there by the other objects?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
What code are you using to test the compiler - maybe you might like to share it so I can try it in debuging the Interpreter?
@BradC: The user will have to worry about that. Hippy and I just need a way to guarantee to reserve space in hub below $200 for the debugger. I am sure there will be other usesas well.
If the user has to worry about it, then why is it an issue to just have ...
DAT
long 0[noparse][[/noparse]debugger#_SPACE]
... at the start of the top object?
The user already has to declare the object and start it in any case.
I'm just trying to figure out why we need to extend the compiler when we can already guarantee that space with a simple addition to the top object (on top of the already required object declaration and object start) - Particularly as doing it this way retains compatibility with the Parallax Compiler and all those that are likely to keep using the existing PropTool?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Hmm!......... not sure sure its a good idea to presume you can speak for others. Albeit = true. No offence intended.
Regards
Ron
··
There's no "need", but it would make things easier. The same lack of need could be levied at any
proposed enhancement.
Breaking compatibility with PropTool isn't really a problem and it will get broken further still unless
homespun ( and others ) will be artificially constrained to handling only source which the PropTool
can also currently handle.
Hopefully any methods of extending our own tools will be elegant enough that Parallax adopts the
same when they have resources to devote to their own tool improvements. I see the best future
for home-grown tools not as competition for each others but as alternatives. At the moment the
ball's in our court for adding enhancements to the Spin language, but I hope they'll all offer the
same capabilities eventually unless a product is designed for a specific niche.
That's a good question and a problem I recognised when I suggested the idea. Perhaps the best
solution is to have _SPACE and @_SPACE as compiler constants which returns the value and the
address of where that space starts for each object ...
CON _SPACE = 256 PUB Main | i repeat i from 0 to _SPACE-1 byte [noparse][[/noparse] @_SPACE + i ] := 0All fair points.
Question.
A) How does the object using the reserved _SPACE know where it starts?
(looks like our posts crossed paths)
(admittedly a far reach, but possible in theory)
@mpark - How have you implemented the _SPACE as a dummy object?
I was thinking if it occupied method 1 in the object table (which is _always_ located in the same position) then it would be a cakewalk to determine where the allocated space actually begins.
.. Just playing devils advocate ..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
In My opinion it would be more practical to have.
ORGSPIN XXX Spin code start (After yous _Space)
ORGTPASM XXX Transparent pasm code
ORGVAR XXX
ORGSTACK XXX
That construction not conflict with PropelerTools and have more reliable Reading.
Samt compiler can test and warn if it is conflict betwen 2 in several sub objects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stuipid question there is atleast one inteligent answer
If you dont ask you wont know
Sapieha
Hrm.. I don't know how mpark does his object compilation, but I compile all my objects separately, then binary link them in a 2 pass process (write out the bytecode, then adjust the object pointers in the method tables). Both this, and the @@@ idea tend to pose problems as you don't know the value of those addresses at compile time. (A problem generally inherent in having relocatable objects I'd guess). I'd have to think pretty hard about how to include constants in the code in such a way as to be able to adjust them at link time.
I guess I could place 5 $3C opcodes in a row into the binary (which should _never_ otherwise occur) and then replace them with a 4 byte constant at link time. Wasteful of bytecode, but only 2 bytes I guess.
The problem is you are never going to know the addresses at compile time, and you are never going to know the size of a compiled object until you have compiled it.
As to how you would use @@@ in a dat block..
Am I thinking to narrowly? Is there an easy way to do it ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Handling @@@ would be a bigger problem.
As to _SPACE going beyond $1FF, I'd not worry about that but allow it. It should be up to the object using it to check @_SPACE < $200 if required. The situation is no worse than a Cog being launched not starting. I wouldn't be adverse to it being a compile error.
The alternative to how it's done now is to compile to an intermediate form ( such as that my bytecode disassembler produces ) at which point it's a single source in traditional 'no object' form and then assemble that. No linking involved as all labels and references will be in the single file.
This single main file could have "#include objectFile.xxx" so each 'compiled object file' can be compared for duplicates and only included once.
If I were writing a Spin compiler I'd do it this way. An advantage is that it's easy to add optimisation stages transparently, for individual objectfile.xxx and the 'everythning included' programfile.xxx - That's why my disassembler produces code in the form it does as one day I hope to write an optimiser and a re-compiler, as well as making it easier for people to write other language compilers producing the intermediate code and not having to worry about assembling and linking the bytecode itself.
All the advantages of late linking / fix-up without the compiler having to worry about keeping track of things.
Something like this wouldn't be a problem to assemble ...
_CLKFREQ LONG 80_000_000 _CLKMODE BYTE XTAL1_PLL16x Checksum BYTE 0 Header WORD Obj_1 WORD Pub_1_1 WORD Stack WORD Var Obj_1 LINK Obj_2 LINK Pub_1_1 LINK Pub_1_2 LINK Obj_2_1 _SPACE_1 LONG 0[noparse][[/noparse]10] _SPACE_2 LONG 0[noparse][[/noparse]100] Pub_1_1 PUSH #_SPACE_1 RET Pub_1_2 RET Obj_2 LINK Vars LINK Pub_2_1 Pub_2_1 PUSH #_SPACE_2 RET Var ... Stack ...Post Edited (hippy) : 9/16/2008 9:18:33 AM GMT
Hrm.. novel idea.
I sort of do this already but only on a per method basis. I compile to a sort of intermediate code represented as a chain of tokens I can loop over to optimise addresses prior to final method assembly. Logically if I chained them all together I could simply assemble the entire object in one hit rather than on a method by method basis. Object chaining will require a bit of thought.. but it's certainly doable.
Gotta think about that some more.. it would certainly make @_SPACE and @@@ in Spin code easy. Not sure I want to think about those constants in DAT though. The Assembler is a different kettle of fish. One could very easily use some spin glue to insert them into DAT prior to use though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Unlike my first attempt at _SPACE, this time I at least tried running a program with non-zero _SPACE (and it worked!). But I didn't actually use the memory. I leave that to you kids with your newfangled debuggers and whatnot.
I have the same problem as Brad as far as @@@ not knowing where it is.
Sapieha, are you familiar Spin bytecode? Not just the opcodes, but the way objects are laid out in memory? It seems to me that your ORGXXX suggestion would be very difficult to implement. But maybe I just have to think about it some more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
Could a similar version work for hub memory (flat)? (not sure where you would place it i.e. pub/pri,etc)
·Uses HUB$ as current location. Just a thought.
@@ gives you the hub address of a spin or DAT symbol at runtime.. why can't you just use a bit of spin setup code to poke that into a variable in DAT somewhere?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
CON ' The following is the object offset needed to be added to [url=mailto:#@xxxx]#@xxxx[/url] in a DAT block of pasm instructions (compiler restriction) DB = $10 '<===== DAT org 0 Pasm rdlong Cog_var, [url=mailto:#DB+@Hub_var]#DB+@Hub_var[/url] 'get variable from hub (lower $200) ..... wrlong Cog_var, [url=mailto:#DB+@Hub_var]#DB+@Hub_var[/url] 'put variable into hub (lower $200) ..... Cog_var long 0-0 'variable in cog ..... Hub_var long 0-0 'accessed directly in hub (not cog!!!)It would be cleaner to replace "[url=mailto:DB_@Hub_var]DB_@Hub_var[/url]" with "@@@Hub_var" (or whatever @@@ is replaced with).
CON _SPACE = 4 Hub_var_addr = $0010 DAT org 0 Pasm rdlong Cog_var, #Hub_var_addr 'get variable from hub (lower $200) ..... wrlong Cog_var, #Hub_var_addr 'put variable into hub (lower $200) ..... Cog_var long 0-0 'variable in cog ..... PUB blah long[noparse][[/noparse]Hub_var_addr] := 666 'use hub variable▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
The requirement is for the assembler code to address hub ram. There is no mechanism for the assembler code to refer to a label defining hub memory. The current workarounds are as I indicated above, or to have the spin code modify the pasm code while still in hub ram before the cog is loaded. This is why many programs just use a piece of hub ram like $7FFC without reserving it.
So this is not possible
Var
stack long[noparse][[/noparse]10]
DAT
long @stack
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
What is the problem with doing it this way?
At least you retain compatibility with the existing compiler!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!