I guess the compiler can allocate static memory space for all parameters and locals and whatever it needs for expression evaluation for every function.
Luckily stack based languages like ALGOL came along so that we can play with interesting data structures, like trees, and recursive decent parsers without having to maintain our own stacks in data.
But I digress.
I think that, if I have a point at all, the last thing the world needs is yet another language and yet another compiler for it. Especially for a chip that has zero point many zeros one percent of the worlds attention.
We have so many already. It would have to be really compelling to get any traction.
I guess the compiler can allocate static memory space for all parameters and locals and whatever it needs for expression evaluation for every function.
Aside: Despite what I said above, I did make a Tiny compiler for the Propeller as a fun exercise for myself. Every programmer should write a compiler for their own language some time. Just don't expect it to go anywhere.
Aside: Despite what I said above, I did make a Tiny compiler for the Propeller as a fun exercise for myself. Every programmer should write a compiler for their own language some time. Just don't expect it to go anywhere.
Note that the Keil stuff is fun to use when you are using function pointers.
I did build an FPGA based multi-processor forth CPU, but I had about as much fun with that as you did with the FFT. I was going to use it to control Belle/Deep Blue style chess move generators/evaluators. It was all hopeless against software running on fast CPUs due to a high branching factor, so I shelved it.
Every programmer should write a compiler for their own language some time.
+1 @Heater
It's very easy to ask "why doesn't the compiler let you do this?" followed by ""I'll write my own better compiler then"
This is when you learn the REAL reason why the compiler won't let you do that and you develop an appreciation of the work done by others before you.
Highly recommend having a go at writing your own language/compiler. I guarantee you will learn valuable programming (life?) lessons
Or write a compiler for an existing language. I wrote a 6800 compiler in 1977 to run on my Singer/ICL minicomputer.
You will appreciate not taking shortcuts. I decided that labels could only be invalid hex names so I didn't require the "$" to signify a hex value.
I then had a label BCC in a BRA BCC statement (it was a conditional branch - cannot recall the exact opcode). Long story short my compiler took the "BCC" to be a hex literal instead of a label. Caused me a huge headache trying to find out why the branch was not ending up at the label BCC.
My friend became tired of requesting ICL add some features to the assembler (compiler) so he wrote his own. Licensed it to customers including ICL. It had extremely powerful macros, etc, etc.
No, uASM is simple enough that I just assemble 'by hand' with hex codes. The twelve-bit register addresses lend themselves nicely to it. I just allocate variables backwards from the top of the 8KB.
Why is it called "uASM" when it is not an assembly language?
What you are describing sounds like a virtual machine or interpreter, like the Spin byte code interpreter or the LMM used by prop-gcc. And you are writing code in that virtual machines instruction set directly in hex.
Perhaps something like "uVM" would be a more appropriate name.
Why is it called "uASM" when it is not an assembly language?
What you are describing sounds like a virtual machine or interpreter, like the Spin byte code interpreter or the LMM used by prop-gcc. And you are writing code in that virtual machines instruction set directly in hex.
Perhaps something like "uVM" would be a more appropriate name.
Hey, I wrote a uHEX system for the 6809 back in 1980. Complete with a debugger, hex code entry, run, halt, single step, break points, register dump, memory dump, load, save. etc. Never thought to call it anything as cool as uHEX.
Comments
Hmmm...I suspect you are right.
I guess the compiler can allocate static memory space for all parameters and locals and whatever it needs for expression evaluation for every function.
Luckily stack based languages like ALGOL came along so that we can play with interesting data structures, like trees, and recursive decent parsers without having to maintain our own stacks in data.
But I digress.
I think that, if I have a point at all, the last thing the world needs is yet another language and yet another compiler for it. Especially for a chip that has zero point many zeros one percent of the worlds attention.
We have so many already. It would have to be really compelling to get any traction.
Sort of like this for C on the 8051? ;-)
http://www.keil.com/support/man/docs/bl51/bl51_overlaying.htm
Aside: Despite what I said above, I did make a Tiny compiler for the Propeller as a fun exercise for myself. Every programmer should write a compiler for their own language some time. Just don't expect it to go anywhere.
Note that the Keil stuff is fun to use when you are using function pointers.
I did build an FPGA based multi-processor forth CPU, but I had about as much fun with that as you did with the FFT. I was going to use it to control Belle/Deep Blue style chess move generators/evaluators. It was all hopeless against software running on fast CPUs due to a high branching factor, so I shelved it.
It's very easy to ask "why doesn't the compiler let you do this?" followed by ""I'll write my own better compiler then"
This is when you learn the REAL reason why the compiler won't let you do that and you develop an appreciation of the work done by others before you.
Highly recommend having a go at writing your own language/compiler. I guarantee you will learn valuable programming (life?) lessons
Or write a compiler for an existing language. I wrote a 6800 compiler in 1977 to run on my Singer/ICL minicomputer.
You will appreciate not taking shortcuts. I decided that labels could only be invalid hex names so I didn't require the "$" to signify a hex value.
I then had a label BCC in a BRA BCC statement (it was a conditional branch - cannot recall the exact opcode). Long story short my compiler took the "BCC" to be a hex literal instead of a label. Caused me a huge headache trying to find out why the branch was not ending up at the label BCC.
My friend became tired of requesting ICL add some features to the assembler (compiler) so he wrote his own. Licensed it to customers including ICL. It had extremely powerful macros, etc, etc.
Brilliant!
Writing parsers for languages or any text formatted data can be a real eye opener.
Then you start to realize why languages have all those ugly $ and whatever brackets and braces.
When you start to think how to make a "clean" language syntax, and how you will ever parse it, it becomes a huge challenge.
Just now I have been playing with the pegjs parser generator and trying to make the rules for it to describe the PASM syntax. Man, it is not easy.
I think, though, that I'll probably end up creating something like C.
I'm testing some ideas for parsers right now...
What you are describing sounds like a virtual machine or interpreter, like the Spin byte code interpreter or the LMM used by prop-gcc. And you are writing code in that virtual machines instruction set directly in hex.
Perhaps something like "uVM" would be a more appropriate name.
I think it should be called uHEX machine code O/S