I wouldn't call the caret positioning a bug. It points to the start of the token ( a string ) which isn't as expected. That it doesn't take the string as it did the one before it looks like a bug.
hippy said...
I wouldn't call the caret positioning a bug. It points to the start of the token ( a string ) which isn't as expected. That it doesn't take the string as it did the one before it looks like a bug.
Sorry, I was not clear. I was actually indicating where the caret is pointing (on my screen, The forum refuses to monospace and stuffs it up) in order to properly point out the error that homespun generates on that file which is actually valid code.
Brad -- @@@ disables bytecode based duplicate elimination. The way Homespun works is it knows what order the objects should be in memory but not where, then it compiles the first object at address 0010, now knows how long it is, compiles the second object putting it after the first, and so forth.
Then bytecode based duplicate elimination occurs, which can move objects around in memory to close up gaps caused by object elimination. Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
Filename-based duplicate elimination occurs much earlier in the process.
Maybe your compiler does things in a different way and can avoid the problem.
Thanks the bug report. I'm vacationing in San Francisco this week, so updates will be sporadic at best.
mpark said...
Brad -- @@@ disables bytecode based duplicate elimination. The way Homespun works is it knows what order the objects should be in memory but not where, then it compiles the first object at address 0010, now knows how long it is, compiles the second object putting it after the first, and so forth.
Then bytecode based duplicate elimination occurs, which can move objects around in memory to close up gaps caused by object elimination. Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
Filename-based duplicate elimination occurs much earlier in the process.
Maybe your compiler does things in a different way and can avoid the problem.
Thanks the bug report. I'm vacationing in San Francisco this week, so updates will be sporadic at best.
m
Neat, enjoy the vacation.
My filename dup detection prevents objects being loaded more than once. I compile all the objects once at PBASE=$10, then I do a bytecode compare to eliminate any duplicate objects before writing them out to the image. If I'm generating a list file, or there is an @@@ in there, I will-recompile the objects starting with the top object in image order until the PBASE of each object stops moving around.
For a list file only, that is once. I need to do this so the list file is generated for the correct PBASE offset.
For @@@ I tend to do it twice plus an additional for a final compare.
So I don't write the objects into memory at all until all the duplicates have been removed, but I do need to re-compile them if I'm generating a list file or there is an @@@ somewhere.
I've left bytecode based dup elimination in place even with @@@. Maybe I ought to disable it also. Perhaps we need feedback from the lads who use @@@.
In the meantime I was wondering if you could add the following "Items" to the compiler.
All items should be parsed as case insensitive.
Item 1
These additions do not create code and should just be ignored by the compiler and not generate errors etc.
End Con
End Var
End Pri
End Pub
End Dat
Basically ignore anything that starts with End and has a white space following.
#Region - and anything else on this line.
#End Region
Item 2
Currently all "Spin Objects" are defined as separate files.
The idea here is to have the objects defined in a single file as well, let me know what you think about that.
Object
End Object
"""""" You said.....
Brad -- @@@ disables bytecode based duplicate elimination. The way Homespun works is it knows what order the objects should be in memory but not where, then it compiles the first object at address 0010, now knows how long it is, compiles the second object putting it after the first, and so forth.
Then bytecode based duplicate elimination occurs, which can move objects around in memory to close up gaps caused by object elimination. Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
""""""
I maybe not understand it at al But.
What not generate separate bytecode objects with Link pseudo code and have elimination in this phase.
After that Link them in old linker maner with given positons in binary code.
Sorry if I mising something but I stil learing me what way it works.
Thanks for this thred and Yours discussion
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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 wont know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
mpark said...
Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
Ahh, the penny just dropped. Yes I see how this could be a problem. I get around it by re-compiling the objects if they move.
It took some major re-engineering as I'd made the assumption that an object would only be compiled once (a rational assumption to make really given the structure of a Propeller object file) and therefore had done nasty things like modifying or removing tokens in-situ.. of course when I went to recompile the object as its absolute address changed, things exploded in my face.
I am not sure that there will be a lot of @@@ in a program.
Just an idea... could you just keep a list of where the @@@ is used and on the final pass fill in the correct values???
As for duplicate removal, it is not important for me now, but I guess as programs grow in size, it will become more of a requirement. At the moment, I have had to make 2 almost identical versions of the RamInterpreter to prevent duplicate removal. Probably there is another way, but that's what I did (easy way).
A question... I tried to put my spin DAT code in a separate file and include it. There is no function to include a source file (con, var, obj, dat pub, pri)·and that would be a nice feature. Just insert source statements in situ, no validation. I have not been able to·import the binary using file as it has overhead bytes so it doesnt compile the target address I require when it's included - so no use for me.
OK guys, here's an interim version. I'm taking time out from nibbling on Ghirardelli chocolates in a cable car going across the Golden Gate bridge, so I hope you appreciate this.
This should fix the ":" problem that Brad found. It also has my first attempt at library paths. It'll look for an environment variable called SPINLIB. It also takes paths on the command line with the -L option (or /L -- options can now begin with - or /).
E.g.
set spinlib=q:\blorb;\Program Files\Parallax Inc\Propeller Tool v1.05.5
homespun017x test /L..\mylib /Lc:\myotherlib\
It'll print out extra stuff (preceded by //) to tell you what it's doing. That'll go away but for now see if it does what you think it should do.
Edit: deleted attachment
Praxis -- what do you have in mind for that "END <whatever>" you requested? An "END" could appear at the start of any line and the line would be ignored? So it would be kinda like a BASIC REM comment?
I'm inclined to agree, but Praxis must have some purpose for this. Something IDE-related? Please let us in on why you want to mess up the grammar, Praxis!
There are those of us who like to have our control constructs delimited with braces or keywords rather than relying on indentation.
I've many times managed to screw up program fragments when copy and pasting them around within a project or between programs as the indentation levels did not match. It's even worse pasting into a different editor or platform etc.
This must be an issue for many as otherwise cntrl-I would not exist in the Spin tool.
So I would welcome Endxxx statements, especially if they were NOT just ignored but actually did what they say.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
There are those of us who like to have our control constructs delimited with braces or keywords rather than relying on indentation.
I've many times managed to screw up program fragments when copy and pasting them around within a project or between programs as the indentation levels did not match. It's even worse pasting into a different editor or platform etc.
This must be an issue for many as otherwise cntrl-I would not exist in the Spin tool.
So I would welcome Endxxx statements, especially if they were NOT just ignored but actually did what they say.
If you change the grammar to that degree, then it will cease to be SPIN really. If you start to implement major changes to the grammar like that, how do you differentiate between Parallax compatible code and code with "relaxed" whitespace requirements but non-spin block styles?
Cluso99 said...
Fantastic - I have just checked the listing output - it is perfect for doing full debugging back to source level, both in pasm and spin.
Glad you could decipher it! I was afraid it would only make sense to me.
If you change the grammar to that degree, then it will cease to be SPIN really. If you start to implement major changes to the grammar like that, how do you differentiate between Parallax compatible code and code with "relaxed" whitespace requirements but non-spin block styles?
You're right : if you don't follow Spin syntax you might as well use something else entirely.
But heater's got a good point too - I agree that the indented block structuring is downright evil. It was ugly when they did it in Occam (I think Leon's got some experience of that ?) but at least Occam had an editor that tried to support it by allowing blocks to be folded away. It's far too easy to delete a line or two and accidentally enclose the following lines in an old block.
I dislike the need to comment out line-ends in Spin, too.
However, I do find the End xx syntax a bit verbose. Do you have #define to replace it with '}' ?
Here's a possible solution :
Since block-indentation is pretty hard to live with unless the editor supports it, and if you're using an alternate compiler you probably aren't using Parallax's IDE, it seems to me that you want free-format input and an intermediate form that's strictly spin. So write the extensions as a preprocessor : the input could be generated with any whitespace, block delimiters, free linewrap, #if directives etc. but the output, if not sent direct to the compiler, would be reformatted to conform to spin block structure and have the conditional parts removed. That output could also then be handled by Parallax's spin compiler directly.
Very fine listings THANKS but litle Error report on command line parameters.
""""
Homespun Spin Compiler 0.18
More than one input file specified
""""
With long Names space separated. If I edit name with no spaces al funktions correct
H:\Arbets\_Div Spin Code\-_ HardWare\HardWare\Homespun Spin compiler>homespun018
.exe /w /d FullDuplexSerial Chip Gracey 4 in 1.spin > FullDuplexSerial Chip Grac
ey 4 in 1.list
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Always a hard one to say how far a language should change from its official syntax to what people prefer. I was not looking forward to an 'indented language' but haven't had too many problems other than accidentally messing that up, usually with cut and paste.
One which often gets me is - "repeat var from start to finish"
Why not - "repeat var := start to finish" ?
or, as I always use until the syntax error - "for var := start to finish" ?
I also fall over "repeat while expr", treating 'repeat' being entirely superfluous except it means something else if a 'repeat' is dropped above it as a 'stop here' bebugging attempt.
One which often gets me is - "repeat var from start to finish"
Why not - "repeat var := start to finish" ?
or, as I always use until the syntax error - "for var := start to finish" ?
Executing that loop for the value of finish is kind of awkward, too - Spin has quite a bit of support for 1-based variables (e.g. through lookup and lookupz) but arrays are zero-based. So iterating over an array means
con
arraysize = 10
var
long array[noparse][[/noparse]arraysize]
pub
repeat i from 0 to arraysize-1
array := something
Which is a pain because, AIUI, arraysize-1 is computed at runtime. Maybe even on every loop.
I suppose the answer is to use the 'constant' operator, though it's an optimisation I'd expect the compiler to do on it's own.
[noparse][[/noparse]sorry .. indentation lost. You know what I mean .. ]
Which is a pain because, AIUI, arraysize-1 is computed at runtime. Maybe even on every loop.
I suppose the answer is to use the 'constant' operator, though it's an optimisation I'd expect the compiler to do on it's own.
[noparse][[/noparse]sorry .. indentation lost. You know what I mean .. ]
bstc will calculate those as a constant if you enable constant folding (-Oc).
I don't default to doing that as my test harness relies on the bytecode being bit for bit compatible with the Parallax compiler.
Comments
I take it this is disabling file/filename based elimination and not object bytecode based ?
I'm just wondering if this is absolutely required. ?
Oh, and another bug for you mpark.
(That caret is pointing at the '"' prior to the colon).
brad@bklaptop2:~/Objects/FemtoBasic_2008-02-28/FemtoBasic$ mono ~/Desktop/homespun017.exe FemtoBasic.spin Homespun Spin Compiler 0.17 parsing FemtoBasic.spin parsing fsrwFemto.spin parsing sdspiFemto.spin parsing vga_Drive.spin parsing comboKeyboard.spin comboKeyboard.spin, line 645: Expected local label shift2 byte $22, 0, 0, 0, 0, "<_>?)!@#$%^&*(", 0, ":", 0, "+" ^▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Sorry, I was not clear. I was actually indicating where the caret is pointing (on my screen, The forum refuses to monospace and stuffs it up) in order to properly point out the error that homespun generates on that file which is actually valid code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (BradC) : 9/21/2008 2:09:05 PM GMT
Then bytecode based duplicate elimination occurs, which can move objects around in memory to close up gaps caused by object elimination. Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
Filename-based duplicate elimination occurs much earlier in the process.
Maybe your compiler does things in a different way and can avoid the problem.
Thanks the bug report. I'm vacationing in San Francisco this week, so updates will be sporadic at best.
m
Neat, enjoy the vacation.
My filename dup detection prevents objects being loaded more than once. I compile all the objects once at PBASE=$10, then I do a bytecode compare to eliminate any duplicate objects before writing them out to the image. If I'm generating a list file, or there is an @@@ in there, I will-recompile the objects starting with the top object in image order until the PBASE of each object stops moving around.
For a list file only, that is once. I need to do this so the list file is generated for the correct PBASE offset.
For @@@ I tend to do it twice plus an additional for a final compare.
So I don't write the objects into memory at all until all the duplicates have been removed, but I do need to re-compile them if I'm generating a list file or there is an @@@ somewhere.
I've left bytecode based dup elimination in place even with @@@. Maybe I ought to disable it also. Perhaps we need feedback from the lads who use @@@.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
In the meantime I was wondering if you could add the following "Items" to the compiler.
All items should be parsed as case insensitive.
Regards
Post Edited (Praxis) : 9/22/2008 10:02:57 AM GMT
"""""" You said.....
Brad -- @@@ disables bytecode based duplicate elimination. The way Homespun works is it knows what order the objects should be in memory but not where, then it compiles the first object at address 0010, now knows how long it is, compiles the second object putting it after the first, and so forth.
Then bytecode based duplicate elimination occurs, which can move objects around in memory to close up gaps caused by object elimination. Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
""""""
I maybe not understand it at al But.
What not generate separate bytecode objects with Link pseudo code and have elimination in this phase.
After that Link them in old linker maner with given positons in binary code.
Sorry if I mising something but I stil learing me what way it works.
Thanks for this thred and Yours discussion
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 wont know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 9/22/2008 10:05:55 AM GMT
Ahh, the penny just dropped. Yes I see how this could be a problem. I get around it by re-compiling the objects if they move.
It took some major re-engineering as I'd made the assumption that an object would only be compiled once (a rational assumption to make really given the structure of a Propeller object file) and therefore had done nasty things like modifying or removing tokens in-situ.. of course when I went to recompile the object as its absolute address changed, things exploded in my face.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I am not sure that there will be a lot of @@@ in a program.
Just an idea... could you just keep a list of where the @@@ is used and on the final pass fill in the correct values???
As for duplicate removal, it is not important for me now, but I guess as programs grow in size, it will become more of a requirement. At the moment, I have had to make 2 almost identical versions of the RamInterpreter to prevent duplicate removal. Probably there is another way, but that's what I did (easy way).
A question... I tried to put my spin DAT code in a separate file and include it. There is no function to include a source file (con, var, obj, dat pub, pri)·and that would be a nice feature. Just insert source statements in situ, no validation. I have not been able to·import the binary using file as it has overhead bytes so it doesnt compile the target address I require when it's included - so no use for me.
Post Edited (Cluso99) : 9/22/2008 1:32:30 PM GMT
This should fix the ":" problem that Brad found. It also has my first attempt at library paths. It'll look for an environment variable called SPINLIB. It also takes paths on the command line with the -L option (or /L -- options can now begin with - or /).
E.g.
set spinlib=q:\blorb;\Program Files\Parallax Inc\Propeller Tool v1.05.5
homespun017x test /L..\mylib /Lc:\myotherlib\
It'll print out extra stuff (preceded by //) to tell you what it's doing. That'll go away but for now see if it does what you think it should do.
Edit: deleted attachment
Post Edited (mpark) : 10/3/2008 9:28:21 AM GMT
Just these statements:
End Con
End Var
End Pri
End Pub
End Dat
End IF
End Case
End Repeat
#Region
#End Region
To be ignored.
If they are to be ignored, just leave them out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Good guess
If it is not too much trouble to allow for it.
I elaborate more once I have done a bit more work.
Cheers
See http://propeller.wikispaces.com/Homespun+Spin+Compiler·for details.
Now to find the time to do just that, after I complete the interpreter.
Nice.. really, really nice.. gives me something to aspire to [noparse]:)[/noparse] (Or imitate!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I've many times managed to screw up program fragments when copy and pasting them around within a project or between programs as the indentation levels did not match. It's even worse pasting into a different editor or platform etc.
This must be an issue for many as otherwise cntrl-I would not exist in the Spin tool.
So I would welcome Endxxx statements, especially if they were NOT just ignored but actually did what they say.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If you change the grammar to that degree, then it will cease to be SPIN really. If you start to implement major changes to the grammar like that, how do you differentiate between Parallax compatible code and code with "relaxed" whitespace requirements but non-spin block styles?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Seems only fair, considering what I'm thinking of imitating from you.
Glad you could decipher it! I was afraid it would only make sense to me.
You're right : if you don't follow Spin syntax you might as well use something else entirely.
But heater's got a good point too - I agree that the indented block structuring is downright evil. It was ugly when they did it in Occam (I think Leon's got some experience of that ?) but at least Occam had an editor that tried to support it by allowing blocks to be folded away. It's far too easy to delete a line or two and accidentally enclose the following lines in an old block.
I dislike the need to comment out line-ends in Spin, too.
However, I do find the End xx syntax a bit verbose. Do you have #define to replace it with '}' ?
Here's a possible solution :
Since block-indentation is pretty hard to live with unless the editor supports it, and if you're using an alternate compiler you probably aren't using Parallax's IDE, it seems to me that you want free-format input and an intermediate form that's strictly spin. So write the extensions as a preprocessor : the input could be generated with any whitespace, block delimiters, free linewrap, #if directives etc. but the output, if not sent direct to the compiler, would be reformatted to conform to spin block structure and have the conditional parts removed. That output could also then be handled by Parallax's spin compiler directly.
Post Edited (agodwin) : 10/3/2008 4:35:06 PM GMT
Very fine listings THANKS but litle Error report on command line parameters.
""""
Homespun Spin Compiler 0.18
More than one input file specified
""""
With long Names space separated. If I edit name with no spaces al funktions correct
H:\Arbets\_Div Spin Code\-_ HardWare\HardWare\Homespun Spin compiler>homespun018
.exe /w /d FullDuplexSerial Chip Gracey 4 in 1.spin > FullDuplexSerial Chip Grac
ey 4 in 1.list
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
One which often gets me is - "repeat var from start to finish"
Why not - "repeat var := start to finish" ?
or, as I always use until the syntax error - "for var := start to finish" ?
I also fall over "repeat while expr", treating 'repeat' being entirely superfluous except it means something else if a 'repeat' is dropped above it as a 'stop here' bebugging attempt.
homespun018.exe /w /d "FullDuplexSerial Chip Gracey 4 in 1.spin" > "FullDuplexSerial Chip Gracey 4 in 1.list"
I don't think this problem is limited to Homespun. Allowing spaces in filenames is a terrible idea, imho.
Don't forget, Spin syntax does allow you to delimit blocks with braces. Might not do what you want though.
Executing that loop for the value of finish is kind of awkward, too - Spin has quite a bit of support for 1-based variables (e.g. through lookup and lookupz) but arrays are zero-based. So iterating over an array means
con
arraysize = 10
var
long array[noparse][[/noparse]arraysize]
pub
repeat i from 0 to arraysize-1
array := something
Which is a pain because, AIUI, arraysize-1 is computed at runtime. Maybe even on every loop.
I suppose the answer is to use the 'constant' operator, though it's an optimisation I'd expect the compiler to do on it's own.
[noparse][[/noparse]sorry .. indentation lost. You know what I mean .. ]
bstc will calculate those as a constant if you enable constant folding (-Oc).
I don't default to doing that as my test harness relies on the bytecode being bit for bit compatible with the Parallax compiler.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!