Another Code Detonation in xBasic
JonnyMac
Posts: 9,107
Many wonder why the Propeller didn't seem to take off with the same fervor of the BASIC Stamp -- I'm one of them. I wonder if it's not as simple as having the basics (pardon the word usage) that some many found so easy in PBASIC included in the Spin language. For example, the BASIC Stamp "Hello, World!" was:
... or some variation, thereof. This was easy, and it stuck. Even "artists" could understand it.
I created methods in my base Spin template for pause, high, low, toggle, and input -- and now I'm doing the same for xBasic but attempting to use native instructions where I can to speed things up; we're already at a slight [speed] disadvantage by using a virtual machine.
As I cannot use "input" as a function name I call that function read_pin. That being the case I decided to make a complimentary function called write_pin. The PASM code compiles fine -- here's the conversion to a function.
The project using it will build fine, but then I get the following message in the debug terminal.
Main: HIGH 0 PAUSE 500 LOW 0 PAUSE 500 GOTO Main
... or some variation, thereof. This was easy, and it stuck. Even "artists" could understand it.
I created methods in my base Spin template for pause, high, low, toggle, and input -- and now I'm doing the same for xBasic but attempting to use native instructions where I can to speed things up; we're already at a slight [speed] disadvantage by using a virtual machine.
As I cannot use "input" as a function name I call that function read_pin. That being the case I decided to make a complimentary function called write_pin. The PASM code compiles fine -- here's the conversion to a function.
def write_pin(pin, state) asm lref 0 // pin --> tos native 0xa0fc0801 // mov t4, #1 native 0x2cbc0805 // shl t4, tos lref 1 // state --> tos native 0x61fc0a01 // and tos, #1 wc native 0x68b3e804 // if_c or outa, t4 native 0x648fe804 // if_nc andn outa, t4 native 0x68bfec04 // or dira, t4 returnx end asm end def
The project using it will build fine, but then I get the following message in the debug terminal.
ILLEGAL OPCODE: STACK 00007BD8, STACK_TOP 00007FD8 PC OP FP SP TOS SP[0] SP[1] SP[2] SP[3] 000001A6 27 00007FC4 00007FC0 00000199 00000000 000001F9 00007FD8 00000000
Comments
Did you use pasm.exe to create those constants?
Yes. Then I copied-and-pasted the hex values into my code. The process is a little tedious, but these bits of code are the exception, not the rule, so it's not a big problem.
Certainly support for in-line ASM would be nice, but an interim solution could be as you suggested to extend the NATIVE keyword to allow multiple lines, and remove most of the NATIVE overhead.
I think that way the size and speed of HEX-asm would be very close to eventual in-line ASM ?
Sounds like it may be easier than I imagined
How large a piece of code are we talking about being the limit here ?
Do you really need to ask ?
I guess the hex syntax still works too ?
I'll check these changes in as soon as we resolve a minor loader issue.
Steve fixed the "minor loader problem" so the PASM assembler and improvements to the NATIVE instruction are checked into Google Code. They should appear whenever Steve does another release of his IDE.