New spin instruction for those getting into the guts of things
BYTECODE()
It lets you insert raw spin bytecodes directly into the method. Can be used pretty much anywhere... see below for an example
You are correct. bstc is exactly what I would want.
Finally found this thread thanks to Cluso99's thread...
When you suggested bstc... I thought you were talking about c language sources:O)
bstc finds my prop and runs as advertised.
I cannot get option 2 to work under OS X 10.4.1.1 on a G5...? I assume that I can just compile and then load it using the loader.
Option 2? As in Load EEProm and Run ?
If not then I'll get it fixed. If bst works for you and bstc does not then I've done something silly as they both share the same compiler/loader code.
Does -p0 or -p1 work for you ?
What happened to 0.04 & 0.05? They were internal fixes and releases incorporated into bst.
Major changes?
- Assembly listing
- Improved Propeller detection / download
- Bugfixes
Have loaded and tested BSTC 07 and have problem to compile.
ERROR.
H:\Arbets\_Div Spin Code\-_ HardWare\HardWare\Homespun Spin compiler\BSTC>bstc -
l -o FullDuplexSerial4in1.spin FullDuplexSerial4in1.spin
Brads SpinTool Compiler v0.07 - Copyright 2008, All rights reserved
Compiled for i386 Win32 at 13:20:24 on 2008/10/21
Loading Object FullDuplexSerial4in1
An unhandled exception occurred at $0041F40B :
EStringListError : List index (277) out of bounds
$0041F40B
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Have loaded and tested BSTC 07 and have problem to compile.
ERROR.
H:\Arbets\_Div Spin Code\-_ HardWare\HardWare\Homespun Spin compiler\BSTC>bstc -
l -o FullDuplexSerial4in1.spin FullDuplexSerial4in1.spin
Brads SpinTool Compiler v0.07 - Copyright 2008, All rights reserved
Compiled for i386 Win32 at 13:20:24 on 2008/10/21
Loading Object FullDuplexSerial4in1
An unhandled exception occurred at $0041F40B :
EStringListError : List index (277) out of bounds
$0041F40B
Can you send me a copy of that spin file please?
I *think* I know where the problem is, but I need to reproduce it precisely to check.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
I'm curious about the level of optimization done by the current compiler. I have lots of code where objects have methods to retrieve internal variables, like this:
PUB GetX
return xValue
And those objects are used like this:
OBJ
SO : "SomeObject.spin"
PUB Function | x, y
x := SO.GetX
Does the current SPIN compiler (or this one by BradC) do anything to optimize this case? Does the compiler actually call the 'GetX' method to get the variable? Given the global knowledge the compiler has, this could become a direct memory location access. Does the compiler make any attempt at 'inlining' like this?
If the compiler doesn't optimize this case, is it possible to directly access VAR members of an object instead of using access functions?
JasonDorie said...
I'm curious about the level of optimization done by the current compiler. I have lots of code where objects have methods to retrieve internal variables, like this:
PUB GetX
return xValue
And those objects are used like this:
OBJ
SO : "SomeObject.spin"
PUB Function | x, y
x := SO.GetX
Does the current SPIN compiler (or this one by BradC) do anything to optimize this case? Does the compiler actually call the 'GetX' method to get the variable? Given the global knowledge the compiler has, this could become a direct memory location access. Does the compiler make any attempt at 'inlining' like this?
If the compiler doesn't optimize this case, is it possible to directly access VAR members of an object instead of using access functions?
Thanks,
Jason
The answer to both of those is no. Here is why.
As objects can be assigned to arrays, there is no certain way of knowing which objects variable segment you are going to access when you do an object call.
It *possibly* could be done for your case where the object is a single, but then the compiler has no real understanding of the contents of the GetX call. It could be far more than just a "return X" and therefore would not be possible to optimise away.
Additionally, until the final object distill and link is done, each object is a completely stand alone bit of memory, so the compiler does not know where the variables for other objects are being placed until the very last moment. You can access the var members of an object quite easily however by passing a reference to the variables address using the @ operator.
The only "optimisation" bst/bstc does at the moment is unused method removal, constant folding and some minor size/speed optimisations to do with addresses and constants. I've not pushed it any further at this time, although dead code removal and branch optimisation are things I'm thinking about (In addition to some tricks to compact the data segment used by STRING() at the end of the object).
Thanks very much Sapieha, that allowed me to pin it down. I'll have a fix today. In the meantime if you don't enable the listfile output it won't crash.
Ok, 0.08 up with the bugfix for the fault Sapieha found.
This would only manifset itself if
A) listfile generation was enabled the last line of the source file was source code
C) the last line of the source file was not terminated with a CR/LF or combination of
Not a required upgrade unless you hit this one specifically.
mpark said...
Umm, no, it's definitely a compiler. Tokenizing is just a small part of what it does.
Example?
I fully agree with mpark here in that spin syntax does not map directly to spin bytecode. There are a number of cases which require you to generate bytecode in a context sensitive fashion.
It's a combination of a compiler/assembler/linker really.
I have mentioned on Homespun thread alternate HEX code listing for PASM.
It is posible for You to have that listing?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
@evanh
From Wikipedia:
"A compiler is a computer program (or set of programs) that translates text written in a computer language (the source language) into another computer language (the target language)...."
bstc compiles a Spin source code to a Spin byte code, and includes also a Propeller Assembler.
@BradC
I'm really impressed of your work (and also of mpark's work, but I like it more if no .NET framework is needed).
With the DAT (assembly) listing your bstc is now perfect suited for a source code debugger (like PASD, but also for Spin).
@Ariba: I have done a Pasm and Spin debugger (zero footprint) and the output listings of both Brad and Michael's compilers are great to do a source code debugger along the lines of your PASD.
Ariba said...
From Wikipedia:
"A compiler is a computer program (or set of programs) that translates text written in a computer language (the source language) into another computer language (the target language)...."
bstc compiles a Spin source code to a Spin byte code, and includes also a Propeller Assembler
The key word is "another".
The Spin interpreter is the same language as the Spin source. The Cog machine code is the same language as it's Assembly. There is no other computer language to convert to.
The bytecode is not a direct representation of the Spin source code. The bytecode interpreter is like a virtual CPU (or generaly a virtual machine). If you look at a listing, made with bstc, then you will see, that a source command is translated to several bytecode instructions, which together build the Spin command. And an other combination of the same bytecodes build then another command.
So the bytecodes are low level instructions, comparable with an assembly language, but shurely better fitted to the Spin language.
I also do not agree with the statement (not from evanh), that Spin is an Interpreter language, and the interpreter fits in the 496 cog ram longs. Spin is a compiler language, that uses an intermediate bytecode, which is executed by a virtual machine in a cog. This is near to the Java approach.
Ok, good nudge. [noparse]:)[/noparse] I should have looked before.
I grabbed a copy of bstc and compiled the example (Ch3-Ex02)-Output.spin. It's very small with a loop and waitcnt. Both commands generated suitably complex code to be called another language. Eg: There was four separate operations to execute the waitcnt: stack Delay, stack CNT, add, waitcnt.
Agreed. Spin is indeed compiled to bytecode. My mistake.
Comments
Looks like a parse error in RGW_HTBasic_Constants_010.spin. Any chance of a copy of the source?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
New spin instruction for those getting into the guts of things
BYTECODE()
It lets you insert raw spin bytecodes directly into the method. Can be used pretty much anywhere... see below for an example
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (Cluso99) : 10/12/2008 12:41:18 PM GMT
You are correct. bstc is exactly what I would want.
Finally found this thread thanks to Cluso99's thread...
When you suggested bstc... I thought you were talking about c language sources:O)
bstc finds my prop and runs as advertised.
I cannot get option 2 to work under OS X 10.4.1.1 on a G5...? I assume that I can just compile and then load it using the loader.
Thanks again
Rich
Option 2? As in Load EEProm and Run ?
If not then I'll get it fixed. If bst works for you and bstc does not then I've done something silly as they both share the same compiler/loader code.
Does -p0 or -p1 work for you ?
Brad
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
works fine.
for any other idiots out there... there is a line in the instructions that looks like this:
-p[noparse][[/noparse]012] - Program Chip on device (-d),
which seems to say use -p012 -d to Program chip on a particular device d...
that's not what it says... it says (for example) use -p2 to compile and load EEProm[noparse]:)[/noparse]
So, your final command line instruction should look something like this
/Parallax/bstc.osx -p2 /Parallax/simpleterminal.spin
Post Edited (rjo_) : 10/13/2008 1:09:07 PM GMT
What happened to 0.04 & 0.05? They were internal fixes and releases incorporated into bst.
Major changes?
- Assembly listing
- Improved Propeller detection / download
- Bugfixes
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (BradC) : 10/21/2008 8:50:53 AM GMT
Have loaded and tested BSTC 07 and have problem to compile.
ERROR.
H:\Arbets\_Div Spin Code\-_ HardWare\HardWare\Homespun Spin compiler\BSTC>bstc -
l -o FullDuplexSerial4in1.spin FullDuplexSerial4in1.spin
Brads SpinTool Compiler v0.07 - Copyright 2008, All rights reserved
Compiled for i386 Win32 at 13:20:24 on 2008/10/21
Loading Object FullDuplexSerial4in1
An unhandled exception occurred at $0041F40B :
EStringListError : List index (277) out of bounds
$0041F40B
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Can you send me a copy of that spin file please?
I *think* I know where the problem is, but I need to reproduce it precisely to check.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
It is file that produced this error.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
PUB GetX
return xValue
And those objects are used like this:
OBJ
SO : "SomeObject.spin"
PUB Function | x, y
x := SO.GetX
Does the current SPIN compiler (or this one by BradC) do anything to optimize this case? Does the compiler actually call the 'GetX' method to get the variable? Given the global knowledge the compiler has, this could become a direct memory location access. Does the compiler make any attempt at 'inlining' like this?
If the compiler doesn't optimize this case, is it possible to directly access VAR members of an object instead of using access functions?
Thanks,
Jason
Tokeniser is prolly the best name.
The answer to both of those is no. Here is why.
As objects can be assigned to arrays, there is no certain way of knowing which objects variable segment you are going to access when you do an object call.
It *possibly* could be done for your case where the object is a single, but then the compiler has no real understanding of the contents of the GetX call. It could be far more than just a "return X" and therefore would not be possible to optimise away.
Additionally, until the final object distill and link is done, each object is a completely stand alone bit of memory, so the compiler does not know where the variables for other objects are being placed until the very last moment. You can access the var members of an object quite easily however by passing a reference to the variables address using the @ operator.
The only "optimisation" bst/bstc does at the moment is unused method removal, constant folding and some minor size/speed optimisations to do with addresses and constants. I've not pushed it any further at this time, although dead code removal and branch optimisation are things I'm thinking about (In addition to some tricks to compact the data segment used by STRING() at the end of the object).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Thanks very much Sapieha, that allowed me to pin it down. I'll have a fix today. In the meantime if you don't enable the listfile output it won't crash.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Umm, no, it's definitely a compiler. Tokenizing is just a small part of what it does.
This would only manifset itself if
A) listfile generation was enabled
C) the last line of the source file was not terminated with a CR/LF or combination of
Not a required upgrade unless you hit this one specifically.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I fully agree with mpark here in that spin syntax does not map directly to spin bytecode. There are a number of cases which require you to generate bytecode in a context sensitive fashion.
It's a combination of a compiler/assembler/linker really.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I have mentioned on Homespun thread alternate HEX code listing for PASM.
It is posible for You to have that listing?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
From Wikipedia:
"A compiler is a computer program (or set of programs) that translates text written in a computer language (the source language) into another computer language (the target language)...."
bstc compiles a Spin source code to a Spin byte code, and includes also a Propeller Assembler.
@BradC
I'm really impressed of your work (and also of mpark's work, but I like it more if no .NET framework is needed).
With the DAT (assembly) listing your bstc is now perfect suited for a source code debugger (like PASD, but also for Spin).
Andy
The Spin interpreter is the same language as the Spin source. The Cog machine code is the same language as it's Assembly. There is no other computer language to convert to.
The bytecode is not a direct representation of the Spin source code. The bytecode interpreter is like a virtual CPU (or generaly a virtual machine). If you look at a listing, made with bstc, then you will see, that a source command is translated to several bytecode instructions, which together build the Spin command. And an other combination of the same bytecodes build then another command.
So the bytecodes are low level instructions, comparable with an assembly language, but shurely better fitted to the Spin language.
I also do not agree with the statement (not from evanh), that Spin is an Interpreter language, and the interpreter fits in the 496 cog ram longs. Spin is a compiler language, that uses an intermediate bytecode, which is executed by a virtual machine in a cog. This is near to the Java approach.
Andy
I grabbed a copy of bstc and compiled the example (Ch3-Ex02)-Output.spin. It's very small with a loop and waitcnt. Both commands generated suitably complex code to be called another language. Eg: There was four separate operations to execute the waitcnt: stack Delay, stack CNT, add, waitcnt.
Agreed. Spin is indeed compiled to bytecode. My mistake.