Shame that Parallax feels so concerned with said "can of worms". All they are likely to do is alienate their most precious commodity: us, the customers. The Propeller is quite an interesting chip with a unique architecture, but it is not the only ball game in town nor unique in its abilities. The likes of ARM, Atmel, Microchip etc have certainly not been afraid to describe their chips and software protocols and do not seem to be doing suffering from doing so.
I seriously doubt the tokenizer would (or, at least, should) be built into the masked ROM of the Prop II. Doing so would be a step backward to the 80's and the likes of the TRS-80 and other "home" computers with BASIC-in-ROM. It would burn way too many bridges, sealing in silicon forever any initially-unnoticed shortcomings in the language and/or the compiler. One thing you don't want to do — especially if you're a small company — is paint yourself into a corner from which escape is unaffordable. Much better, if the current reliance on Windows is a concern (which it should be), would be a suite of cross-development tools that can be be ported to any host operating system.
Only if the if the tokenizer were to exist in internal flash or some other reprogrammable memory, would a tokenizer-on-chip approach make sense by averting substantial risk. But, even then, embedding any function that gets used only for development and not for running is, in my opinion, a waste of precious silicon.
Phil Pilgrim (PhiPi) said...
Doing so would be a step backward to the 80's and the likes of the TRS-80 and other "home" computers with BASIC-in-ROM. -Phil
Stepping back to 80s home computer methods is why quite a lot of us have embraced the Prop! (e.g. the entire Hydra community)
I don't have the thread to hand, but I'm pretty sure one of the Parallax guys said that the the development environment either definitely or very likely was to be put into the ROM. I agree there are risks to doing so of bugs in the development environment. But future revision of the chip could contain dev tool updates. If people want the new version of the dev system, they need only replace the Prop on their dev system, not recall every Prop II chip they ever shipped in a device. It's only the interpreter in the ROM that must stay the same once released. And that's been well tested in Prop I.
Also the existence of an on-chip compiler doesn't preclude the use of the existing PC based Proptool, if it's suitably updated.
And I imagine that the compiler on chip is going to be decoupled from the IDE, such that you can use an IDE on a PC and use the Prop based compiler. Which means that any IDE defects are updatable, and that third party IDEs will be an easy option.
As to the silicon, the Prop I has Sin and Log tables in ROM, which are unused by 99% of apps. So I take it that on board ROM isn't expensive or in short supply.
But who knows? I doubt anything is yet absolutely certain.
The idea is to release the next chip initially without the integrated development environment on the chip, then after some maturation revising the ROM mask to include the IDE. The PC method of programing will remain possible.
One of my concerns is that the developers' appetite for making extensions to Spin or enhancements to the IDE will be diminished — even below where it seems to exist now — if it means forking the PC tools away from an embedded IDE. Even with the potential flexibility offered by an additional PC-centric development environment, I have my doubts that that flexibility would be realized if it's being held back by the existence of incompatible or less capable embedded tools.
Consequently, once the ROM mask is created, input from the user community regarding improvements would, I should imagine, be less welcome than it might be otherwise. As a user, it's important to me to believe that Parallax keeps an open ear and maintains an open mind regarding suggestions from the community and strives to accommodate the better ones. But once the "crypt is sealed" such accommodation becomes less certain.
I'd much rather see the ROM being used to benefit the run-time environment. Built-in soft peripherals like serial I/O, I2C routines, TV_text, and the like would be an example of this. This is the kind of embedded funcitonality that makes the BASIC Stamps such an enduring success. At least if a particular embedded feature proves unsatisfactory to the user, he can substitute one of his own without discarding the whole lot of them. But with an embedded IDE it would be all or nothing. And, should a PC-based IDE evolve beyond the capabilities of an embedded one, who would want to use the embedded one? In such a case the entire IDE ROM space becomes so much dead weight.
Phil Pilgrim (PhiPi) said...
And, should a PC-based IDE evolve beyond the capabilities of an embedded one, who would want to use the embedded one? In such a case the entire IDE ROM space becomes so much dead weight.
-Phil
People who run Macs or Linux. People running a version of Windows that PropTool is not compatible with. Users of some hypothetical future computer that follows Andre's ideal of an 80s style home computer updated for the 2000s.
In a nutshell anyone who for one reason or another doesn't want to be tied to Windows.
I guess "PC" was too loaded an acronym. My use of it anyway wasn't meant to reflect a Windows-centric bias, as my earlier comments about portability should have indicated. Both Macs and Linux machines are "personal computers" — in my mind at least.
Anyway, 'sorry for the raised hackles!
-Phil
Addendum: After a good night's sleep, there's something else I wonder about: If the IDE exists on two distinct platforms (Prop II and generic "PC"), what tools will the developers be using to write and maintain it? Will there be one source, written in C perhaps, that compiles to both the Prop and a PC? Or will two distinct sets of incompatible source files have to be maintained, then resynchronized whenever a new ROM mask is created?
I too really don't see the need for a ROM-based development system and would much prefer to see resources being put into the desktop-based IDE or elsewhere. It's not that I'm against it, but it seems to be a misdirection of valuable resources, and the ROM could be used for much more useful things.
A ROM-based system could be the equivalent of the One Laptop Per Child for the embedded market, a potential resurgence of the home computers of the 80's. Maybe there's some need for it - standalone systems in schools - but I'm not sure what real benefit there is. The argument that it helps out non-Windows users is I believe a red herring.
As the system will have to use SD Card or something similar for storage, why not simply put it on there and make it bootable from SD ? Alternatively, in external I2C Eeprom. That also means it can be used by early adopters of the Prop II.
CardboardGuru said...
And indeed I must say that knowing that was the roadmap was the end of my idea to produce an independent Spin compiler. Who wants to work on a dead end project?
Providing the Propeller remains externally programmable, and the indications are it will, I see there being as much validity in alternative Spin Compilers as there ever was. Even more-so for the Propeller II where Spin to Assembler compilation would be a possibility.
Damien Allen said...
Just wondering if you have made any progress in this area? I've learned a lot from what you've posted so far....need more information.....
I took some time out to actually use the Propeller and get to grips with both Spin and Assembler and haven't done any more on this, but could be heading back this way soon. The decompiler needs a rewrite and I've some ideas on how to do that. There were some things I wasn't aware of ( overlap of 'res' with Spin ) which means the current decompiler is sometimes less useful than it could be. I'd parse the image somewhat differently next time round.
What sort of "more information" were you looking for ?
What hasn't become apparent is that the PC (Windows & their equivalents) have wandered a long way
from their roots. What do you do with your PC? I'll bet if it's for home use, you use it for
some type of communication. (email, web, voip, etc) Even PC gaming is on the
decline as most gaming is moving toward gaming platforms, (playstation, xbox, etc.)
The 80's microcomputer was at home playing games, they and their predecessors were machines for geeks.
A place to learn programming, technology, etc. Many of us have embraced the prop because
it has provided a place to learn and experiment again. If the IDE is placed on the prop, I
don't think this should be seen as a step backward, just a step to give back what we lost.
I won't mind disconnecting my PC from the Prop permanently as long as there is a method
that I can use to export and share my code as there is now. A modern version of an 80's
style computer... perfect...
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Just getting started with Propeller?
I was thinking of trying to write a 'simple C' i.e a subset of C, to spin bytecode compiler or translator (i'm not sure which is the more accurate description). I'm by no means a decent programmer by any sense of the word but I learn by doing and would like to improve my skills. My university doesn't teach compiler design as part of the CS degree so i'm on my own!
What you say about PCs wandering from their roots is very true. I, too, experience occasional pangs of yearning for the simpler days of the '80s. And I've certainly lost all sense of control or true "ownership" of my Windows and Mac PCs. (Even my Linux box is little better in that regard.) But to bet a bleeding-edge chip design and acres of masked ROM on a market share driven by nostalgia? I don't get it, but I'm willing to wait and see...
Compiler design is not something to attempt without some background. I would recommend getting a copy of Compilers: Principles, Techniques, and Tools by Aho, Ullman, et al. (the "dragon book"). Having this book in hand, you can begin your journey with greater confidence.
The complaints about the real estate consumed is a little misplaced, each block of ROM occupies less than 1/6th the space of an equivalent block of RAM. Also we have been contemplating using multibit ROM techniques, which would mean no additional real estate would be needed if we chose that path (I know the technique will not be used for the initial mask, but I don't know if it would be used in subsequent masks).
Code Libraries also have to be a later addition since they will need to mature as well.
> I would recommend getting a copy of Compilers: Principles, Techniques, and Tools by Aho, Ullman, et al.
> (the "dragon book"). Having this book in hand, you can begin your journey with greater confidence.
That book is quite bad!
The best book ever ever about that subject is Niklaus Wirth; Compiler Construction. First edition (in German) is 1986 IIRC, but still right to the point. It later was translated.
With this book, you can write your first compiler in less than two weeks (for a virtual machine).
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Thanks for the helpful pointer! I have a great deal of respect for Niklaus Wirth, having once been an avid Modula 2 user. I wasn't familiar with that book, however, and shall have to add it to my library. Here is the link. And at only $29.99 (used), it's way cheaper than the one I recommended!
-Phil
Thanks, Damien! Free is cheaper still!
Post Edited (Phil Pilgrim (PhiPi)) : 11/27/2007 11:15:30 PM GMT
I still believe it to be a mammoth task and I wish someone would've done it already. I had hoped hippy may have started it but I think he is a little busy [noparse]:)[/noparse]
Yes, I'm afraid I've been all over the place, like a child in a sweet shop since I got my propeller; there's been so much fun to be had ! Unfortunately that means a lot of changing focus and many unfinished projects. Moving between projects has been a great fast-track into the Propeller but I ought to choose something to primarily focus on.
I think the next 'fun project' will be a minimal C-like compiler to Spin bytecode, or at least some proof of concept code.
> Thanks for the helpful pointer! I have a great deal of respect for Niklaus Wirth, having once been an avid Modula 2 user.
That book is really incredibly good.
I have written at least five commercial interpreters. Three of them fully interpreted code. One was a language to translate a data-format into another. Two interpreter parsed the source and built an evaluation tree. That evaluation-tree was then interpreted. That was like an object-oriented virtual machine and *very* fast.
Some of them had a variable trace and you could step through the code, set breakpoints, go-to-cursor etc.
One interpreter was written in Pascal, one in Modula-2 and the others in C or C++.
I always grabed for that book when I wrote the parser.
But designing the language is quite the biggest task. Beside debugging.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
I've got the Dragon book Phil recommended, and it's pretty much regarded as the definitive text on Compilers. But I found it to be extremely hard going. I'd want it to accompany a year long course on the subject, not a self-learning read.
Thanks for the link to Niklaus Wirth's book, I'll give it a go next time I've got some language thing in mind.
Hippy: An extensible macro-assembler or a C or Pascal or Java (sort of) to "generic" assembler would be much more useful than a C->Spin translator. But that is just a wish of mine. I'd wanted to write a compiler for .... 10 years already ?, I never did. In the future I hope I wll understand the subject better.
@ Ale, Damien Allen : You both make good points. I have a C-like compiler partially finished which generates P-Code then targets Microchip processors and for me it would be easiest to alter that and add a new back-end. That would be Spin bytecode initially and Assembler later.
That's written in TurboBasic/PowerBasic for 16-bit MS-DOS, but I have my own software which converts source to VB6 and Perl ( needs some work on that ), so there will hopefully be some platform independence with it. Not perfect, but better than nothing.
As well as being C-like, it's also VB-like ( both can be mixed in the same source ) and Pascal-like to the extent that subroutines and functions can be nested -
long MyFunc( long a, long b )
{
return a + b;
}
Function MyFunc( a As Long, b As Long ) As Long
MyFunc = a + b
End Function
It's going to end up more as Spin looking like C or VB than true C or VB. I'm no compiler whizkid so you get what I can give
I've spent some time looking at the sources and have a good idea of what needs doing, so will see what I can generate. As always, no promises on anything.
Regarding the on-chip IDE in the upcoming Prop II:
You said...
The complaints about the real estate consumed is a little misplaced, each block of ROM occupies less than 1/6th the space of an equivalent block of RAM.
Okay, given that you have oodles of ROM (still a finite resource, nonetheless) to play with, how will the synchronization between the ROM version and PC version of the Spin compiler be managed? Having a compiler written in two languages seems untenable from a maintenance standpoint. I don't know if you're old enough to remember the Z8671 BASIC interpreter chip from Zilog. It had an onboard source-language interpreter which was itself written in P-code and run via another interpreter written in Z8 assembly language. This is an idea that may be useful for the Prop II. If the compiler itself could be compiled to P-code which ran on both the Prop II and a host computer, there would be only one compiler to maintain, instead of two. What would be even better is if the compiler had built-in hooks for language extensions, so that these extensions could be uploaded to EEPROM to patch and/or extend the on-chip version of the compiler.
I'm still not convinced an on-chip IDE is a necessary or desirable route to take. I'd much rather see that effort go towards freeing the PC dev environment from Windows, so it could be used with Linux and OS/X. Although I'm relatively happy with Windows XP, it's likely to be the last Microsoft OS I ever buy; and eventually the computer it runs on is going to wear out. I know I'm far from alone in that regard.
Unfortunately, I'm not able to really dabate the merits/demirits of an integrated IDE, simply forwarding the current thoughts on the subject. Chip has a strong leaning towards incorporating the IDE and cutting the dependence on PCs, so it will likely be included at some point. The idea behind waiting for it's maturation before inclusion is to get the compiler into a stable release point so there should be little if any need for futher revisions. To my knowledge, the compiler for the Prop I has only had one revision since release and that was to accomodate Chip's need to complete the vocal sythesis object. So there should be little if any divergence between the PC and Prop based compiler. I don't know what the methodology for incorporating the compiler will be, I don't think we have gotten to the point yet where we need to worry about it.
Probably just my inexperience, but embedding the IDE in Prop2 seems fraught with danger. Sure, the current compiler's been remarkably stable, but it HAS been updated for Chip's requirement. What's to say another 'requirement' wouldn't come along too?
Also; whilst the _compiler's_ been stable, the *IDE* has been sorely lacking (IMHO) for a very long time. If _that_ get's embedded, aren't we just gonna be 'stuck' with it?
Only sensible solution - if we MUST have the IDE embedded - is to at least allow the 'hooks' that Phil mentioned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Again we will not abandon the PC route, those that don't want to use the onboard IDE are not forced to. Honestly I don't know the details of how it will work, I haven't talked to Chip about the subject for months, I don't think it's been formalized yet, much bigger fish to fry for the foreseable·future.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
Only if the if the tokenizer were to exist in internal flash or some other reprogrammable memory, would a tokenizer-on-chip approach make sense by averting substantial risk. But, even then, embedding any function that gets used only for development and not for running is, in my opinion, a waste of precious silicon.
-Phil
Stepping back to 80s home computer methods is why quite a lot of us have embraced the Prop! (e.g. the entire Hydra community)
I don't have the thread to hand, but I'm pretty sure one of the Parallax guys said that the the development environment either definitely or very likely was to be put into the ROM. I agree there are risks to doing so of bugs in the development environment. But future revision of the chip could contain dev tool updates. If people want the new version of the dev system, they need only replace the Prop on their dev system, not recall every Prop II chip they ever shipped in a device. It's only the interpreter in the ROM that must stay the same once released. And that's been well tested in Prop I.
Also the existence of an on-chip compiler doesn't preclude the use of the existing PC based Proptool, if it's suitably updated.
And I imagine that the compiler on chip is going to be decoupled from the IDE, such that you can use an IDE on a PC and use the Prop based compiler. Which means that any IDE defects are updatable, and that third party IDEs will be an easy option.
As to the silicon, the Prop I has Sin and Log tables in ROM, which are unused by 99% of apps. So I take it that on board ROM isn't expensive or in short supply.
But who knows? I doubt anything is yet absolutely certain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
One of my concerns is that the developers' appetite for making extensions to Spin or enhancements to the IDE will be diminished — even below where it seems to exist now — if it means forking the PC tools away from an embedded IDE. Even with the potential flexibility offered by an additional PC-centric development environment, I have my doubts that that flexibility would be realized if it's being held back by the existence of incompatible or less capable embedded tools.
Consequently, once the ROM mask is created, input from the user community regarding improvements would, I should imagine, be less welcome than it might be otherwise. As a user, it's important to me to believe that Parallax keeps an open ear and maintains an open mind regarding suggestions from the community and strives to accommodate the better ones. But once the "crypt is sealed" such accommodation becomes less certain.
I'd much rather see the ROM being used to benefit the run-time environment. Built-in soft peripherals like serial I/O, I2C routines, TV_text, and the like would be an example of this. This is the kind of embedded funcitonality that makes the BASIC Stamps such an enduring success. At least if a particular embedded feature proves unsatisfactory to the user, he can substitute one of his own without discarding the whole lot of them. But with an embedded IDE it would be all or nothing. And, should a PC-based IDE evolve beyond the capabilities of an embedded one, who would want to use the embedded one? In such a case the entire IDE ROM space becomes so much dead weight.
-Phil
People who run Macs or Linux. People running a version of Windows that PropTool is not compatible with. Users of some hypothetical future computer that follows Andre's ideal of an 80s style home computer updated for the 2000s.
In a nutshell anyone who for one reason or another doesn't want to be tied to Windows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Me!
I actually, do not even care about Spin. I just want asm.
Anyway, 'sorry for the raised hackles!
-Phil
Addendum: After a good night's sleep, there's something else I wonder about: If the IDE exists on two distinct platforms (Prop II and generic "PC"), what tools will the developers be using to write and maintain it? Will there be one source, written in C perhaps, that compiles to both the Prop and a PC? Or will two distinct sets of incompatible source files have to be maintained, then resynchronized whenever a new ROM mask is created?
A ROM-based system could be the equivalent of the One Laptop Per Child for the embedded market, a potential resurgence of the home computers of the 80's. Maybe there's some need for it - standalone systems in schools - but I'm not sure what real benefit there is. The argument that it helps out non-Windows users is I believe a red herring.
As the system will have to use SD Card or something similar for storage, why not simply put it on there and make it bootable from SD ? Alternatively, in external I2C Eeprom. That also means it can be used by early adopters of the Prop II.
Providing the Propeller remains externally programmable, and the indications are it will, I see there being as much validity in alternative Spin Compilers as there ever was. Even more-so for the Propeller II where Spin to Assembler compilation would be a possibility.
I took some time out to actually use the Propeller and get to grips with both Spin and Assembler and haven't done any more on this, but could be heading back this way soon. The decompiler needs a rewrite and I've some ideas on how to do that. There were some things I wasn't aware of ( overlap of 'res' with Spin ) which means the current decompiler is sometimes less useful than it could be. I'd parse the image somewhat differently next time round.
What sort of "more information" were you looking for ?
from their roots. What do you do with your PC? I'll bet if it's for home use, you use it for
some type of communication. (email, web, voip, etc) Even PC gaming is on the
decline as most gaming is moving toward gaming platforms, (playstation, xbox, etc.)
The 80's microcomputer was at home playing games, they and their predecessors were machines for geeks.
A place to learn programming, technology, etc. Many of us have embraced the prop because
it has provided a place to learn and experiment again. If the IDE is placed on the prop, I
don't think this should be seen as a step backward, just a step to give back what we lost.
I won't mind disconnecting my PC from the Prop permanently as long as there is a method
that I can use to export and share my code as there is now. A modern version of an 80's
style computer... perfect...
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just getting started with Propeller?
Propeller Cookbook
PropDOS
What you say about PCs wandering from their roots is very true. I, too, experience occasional pangs of yearning for the simpler days of the '80s. And I've certainly lost all sense of control or true "ownership" of my Windows and Mac PCs. (Even my Linux box is little better in that regard.) But to bet a bleeding-edge chip design and acres of masked ROM on a market share driven by nostalgia? I don't get it, but I'm willing to wait and see...
-Phil
Compiler design is not something to attempt without some background. I would recommend getting a copy of Compilers: Principles, Techniques, and Tools by Aho, Ullman, et al. (the "dragon book"). Having this book in hand, you can begin your journey with greater confidence.
-Phil
Code Libraries also have to be a later addition since they will need to mature as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 11/27/2007 10:09:08 PM GMT
> (the "dragon book"). Having this book in hand, you can begin your journey with greater confidence.
That book is quite bad!
The best book ever ever about that subject is Niklaus Wirth; Compiler Construction. First edition (in German) is 1986 IIRC, but still right to the point. It later was translated.
With this book, you can write your first compiler in less than two weeks (for a virtual machine).
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
http://www.oberon.ethz.ch/WirthPubl/CBEAll.pdf
Link to said book [noparse]:)[/noparse]
Post Edited (Damien Allen) : 11/27/2007 11:09:28 PM GMT
Thanks for the helpful pointer! I have a great deal of respect for Niklaus Wirth, having once been an avid Modula 2 user. I wasn't familiar with that book, however, and shall have to add it to my library. Here is the link. And at only $29.99 (used), it's way cheaper than the one I recommended!
-Phil
Thanks, Damien! Free is cheaper still!
Post Edited (Phil Pilgrim (PhiPi)) : 11/27/2007 11:15:30 PM GMT
I think the next 'fun project' will be a minimal C-like compiler to Spin bytecode, or at least some proof of concept code.
That book is really incredibly good.
I have written at least five commercial interpreters. Three of them fully interpreted code. One was a language to translate a data-format into another. Two interpreter parsed the source and built an evaluation tree. That evaluation-tree was then interpreted. That was like an object-oriented virtual machine and *very* fast.
Some of them had a variable trace and you could step through the code, set breakpoints, go-to-cursor etc.
One interpreter was written in Pascal, one in Modula-2 and the others in C or C++.
I always grabed for that book when I wrote the parser.
But designing the language is quite the biggest task. Beside debugging.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Thanks for the link to Niklaus Wirth's book, I'll give it a go next time I've got some language thing in mind.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
That's written in TurboBasic/PowerBasic for 16-bit MS-DOS, but I have my own software which converts source to VB6 and Perl ( needs some work on that ), so there will hopefully be some platform independence with it. Not perfect, but better than nothing.
As well as being C-like, it's also VB-like ( both can be mixed in the same source ) and Pascal-like to the extent that subroutines and functions can be nested -
long MyFunc( long a, long b )
{
return a + b;
}
Function MyFunc( a As Long, b As Long ) As Long
MyFunc = a + b
End Function
It's going to end up more as Spin looking like C or VB than true C or VB. I'm no compiler whizkid so you get what I can give
I've spent some time looking at the sources and have a good idea of what needs doing, so will see what I can generate. As always, no promises on anything.
Regarding the on-chip IDE in the upcoming Prop II:
Okay, given that you have oodles of ROM (still a finite resource, nonetheless) to play with, how will the synchronization between the ROM version and PC version of the Spin compiler be managed? Having a compiler written in two languages seems untenable from a maintenance standpoint. I don't know if you're old enough to remember the Z8671 BASIC interpreter chip from Zilog. It had an onboard source-language interpreter which was itself written in P-code and run via another interpreter written in Z8 assembly language. This is an idea that may be useful for the Prop II. If the compiler itself could be compiled to P-code which ran on both the Prop II and a host computer, there would be only one compiler to maintain, instead of two. What would be even better is if the compiler had built-in hooks for language extensions, so that these extensions could be uploaded to EEPROM to patch and/or extend the on-chip version of the compiler.
I'm still not convinced an on-chip IDE is a necessary or desirable route to take. I'd much rather see that effort go towards freeing the PC dev environment from Windows, so it could be used with Linux and OS/X. Although I'm relatively happy with Windows XP, it's likely to be the last Microsoft OS I ever buy; and eventually the computer it runs on is going to wear out. I know I'm far from alone in that regard.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Also; whilst the _compiler's_ been stable, the *IDE* has been sorely lacking (IMHO) for a very long time. If _that_ get's embedded, aren't we just gonna be 'stuck' with it?
Only sensible solution - if we MUST have the IDE embedded - is to at least allow the 'hooks' that Phil mentioned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 11/29/2007 7:02:27 PM GMT