The case sensitivity thing would be an option, you would turn on if you wanted it for your code.
Sorry, Roy, but I can't quite see that being an option. Case sensitivity should be all or nothing, since it's such an integral aspect of the language. Making it optional will be too confusing for newcomers to Spin. I'm gonna have to side with "nothing" in this case, I'm afraid. But I'd be all for enforcing case-coherency in the compiler. At least that would pave the way for change if we decide that case-sensitivity isn't such a bad idea after all. Can we at least talk about a two-step process?
Not sure what you mean precisely by segments sizes in Spin/PASM. Do you just mean allowing for PASM bigger than 496 longs, and spin larger than 32k?
By compiler listing outputs, do you mean dumping some form of human readable version of the spin bytecode?
Hi Roy,
Thanks for explaining. On the above two points, PASM should be allowed to be any size (e.g. 16Mb) to allow for LMM and XMM programs, and compiler listings are necessary if you want to use a debugger (e.g. to examine memory addresses). Look at the listings that both HomeSpun and BST can produce.
I think listings are a requirement at some point in time. Just want the compiler to be working and then opened first.
The other thing required quite quickly - perhaps it is required by GCC, and I know Ross just asked for it, is larger pasm to support LMM/XMM. Maybe we require an new pasm instruction for this particular case. It is the jumps that cause the issue, where the address has to be held in the following long. Or a compiler directive.
If you are wanting huge amounts of LMM PASM in a program, either hand written or compiled from some language, it suggests to me that you are not working in Spin. So why not just use the gas assembler that comes with propgcc?
Cluso99,
I don't believe the GCC stuff needs this code to compile LMM/XMM output. Pretty sure they just produce output that GAS assembles into the binary that they run for that. The feature that has been requested of me for propgcc is the -c option from BSTC, that dumps out only DAT sections (compiled). I think it's only used for interfacing from GCC to pre-existing objects written in pasm.
I'm assuming for Ross's needs that I'll only need to have an option that allows for PASM code to be larger than 496 longs. I would expect his compiler to produce the LMM/XMM specific "opcodes" mixed into the PASM in the DAT section. The existing DAT block compile handles mixed pasm and data.
tdlivings,
Your reported bug is fixed with the current stuff up in the repository (r28).
If you are wanting huge amounts of LMM PASM in a program, either hand written or compiled from some language, it suggests to me that you are not working in Spin. So why not just use the gas assembler that comes with propgcc?
Easy! So you can use all the OBEX Spin objects from any language! But even if that were not possible (which it is) why would you want to make everything dependent on propgcc when there is simply no need to do so? Why restrict all non-Spin development to the one tool chain?
BST and Homespun have been able to compile LMM programs for years now. All it takes is the ability to create PASM programs larger than 496 instructions, and have symbol tables larger than 1000 symbols (or whatever is the limit hardcoded in the Parallax compiler) - do that and you can compile LMM, SPIN and PASM programs all with one compiler. Or any other language you want just by using a suitable preprocessing step.
Too easy!
Ross.
P.S. I'm not knocking propgcc - but it is certainly a kind of overkill to have to use it as an assembler just because the standard Parallax assembler has arbitrary and unnecessary internal size limits!
I'm assuming for Ross's needs that I'll only need to have an option that allows for PASM code to be larger than 496 longs. I would expect his compiler to produce the LMM/XMM specific "opcodes" mixed into the PASM in the DAT section. The existing DAT block compile handles mixed pasm and data.
Yes, that (plus the ability to have larger symbol tables) is a fair summary of the minimum requirement to support any language in conjunction with Spin. The propgcc route is of course another - but it is much more complex, partly because of all the other baggage you have to bring to the process of compiling programs with gcc.
So you can use all the OBEX Spin objects from any language!
That is kind of orthogonal to any LMM support as most PASM we want to pull out of existing Spin objects is not going to be LMM.
We only need the -c switch to do that.
Of course limits on the length of PASM and number of symbols should be removed. Actually having almost never used the Prop Tool I hadn't realized there were such hard limits.
It's one of those odd days that I find myself agreeing with you:)
I wonder if there is a way for a new compiler to save some memory?
One of the projects this group has done as a collective is emulate an ancient processor called the Z80, and while this may seem a terribly old fashioned processor, it was at least designed to access 64k of memory easily. The propeller, on the other hand, modern chip that it is, has only 32k, and if you write a standard program and load up a spin processor and 7 cogs with their programs, you lose 14k of that 32k.
That is nearly half the available memory, and memory is very precious.
There are a number of solutions, one of which is to split the pasm and the spin code for objects and to store the pasm part as a separate file that is loaded off an SD card into a common 2k bank of ram and then into a cog. This process saves 12k of the 32k, and another 2k if you recycle the load buffer. But the catch is you need an SD driver which then uses up most of the 14k you just saved
I have been pondering what happens if you compile a standard spin program with lots of included objects, and it seems to be that the proptool leaves the 2k cog code scattered at random locations through memory.
I wonder if a compiler could at least group all the DAT code together at one location? It wouldn't matter if it was at the beginning or the end - all you would need to do is declare a variable just before the first DAT and that could become a pointer to the entire DAT group.
Would a compiled program know or care where DAT code was in hub?
What this could then mean is that if you have the first DAT declaration (which you could declare in the main program), and you were loading up n cogs, then you have a block of 2048*n k of hub space in a group that your program can access as a buffer (or whatever) once the cogs have all loaded.
I'm not sure if other compilers do this already, but it could be very handy to recycle that space as, say, an SD card buffer, or a buffer for a screen, or a font library or whatever. And I don't think it would change execution speed?
There's still one place left in the Spin language definition where actual file and directory names must be provided: that awful file pseudo-op. I was hoping to see it deprecated by the #INCLUDE pre-processor directive, but that would not work, since #INCLUDE doesn't do any data translation. To get rid of file from the language definition, perhaps it could be converted to a #FILE pre-processor directive, which translates the bytes of the file into byte statements. Of course, file will have to remain for awhile for backward compatibility, but at least there could be a roadmap toward making it redundant, since it really should not be part of the language.
I wonder if there is a way for a new compiler to save some memory?
One of the projects this group has done as a collective is emulate an ancient processor called the Z80, and while this may seem a terribly old fashioned processor, it was at least designed to access 64k of memory easily. The propeller, on the other hand, modern chip that it is, has only 32k, and if you write a standard program and load up a spin processor and 7 cogs with their programs, you lose 14k of that 32k.
Maybe this is done already - any thoughts?
Since Parallax is using 64k EEPROMs on the new boards, why not store a PASM overlay in the upper 32k, then load that dynamically. No RAM overhead penalty and no SD penalty.
I wasn't aware that the GCC group were using yet another pasm compiler. How many compilers are Parallax developing?
We have tried to have the compiler updated (PropTool) for so long that Michael Park (homespun) and Brad Campbell (bst) both wrote compilers, both free, and were being supported until something with Parallax seemed to happen. Now they are successful, Parallax shuns them and produces TWO of it's own.
What gives here??? Is Parallax becoming a Microsoft (remember Netscape and Internet Explorer)???
The SPIN-on-SPIN compiler is mostly a BLOB of data included in a SPIN file, why it couldn't have been source code, I don't know. I talked with Brad and he seemed to worry about support and accused of being a hack programmer.
I had offered to write a SPIN compiler a short while ago, that's when Ken sent me an update of the then current state of their effort.
I wrote a compiler and opcode interpreter ~10 years ago for the company I was working for. Honestly I probably wouldn't have done the same thing today, but at the time I was reading the FLEX/YACC book and it scratched an itch.
Cluso99,
In order to facilitate GCC, which is a requirement, they needed to build a variant of GAS that supported PASM. That's my understanding of it.
Also, non of the existing compilers at the time were open source or willing to go open source.
You seem to really want Parallax to be bad guys in this, and they just aren't.
I wasn't aware that the GCC group were using yet another pasm compiler. How many compilers are Parallax developing?
We have tried to have the compiler updated (PropTool) for so long that Michael Park (homespun) and Brad Campbell (bst) both wrote compilers, both free, and were being supported until something with Parallax seemed to happen. Now they are successful, Parallax shuns them and produces TWO of it's own.
What gives here??? Is Parallax becoming a Microsoft (remember Netscape and Internet Explorer)???
We are developing one compiler, the recent x86 to C conversion which Roy has completed.
Brad (BST) also wants our compiler as his is in some ways not validated by Parallax. And plus, how are we supposed to "open source" something we don't own? As you mentioned, Michael and Brad's compilers are owned by Michael and Brad, not Parallax. Giving away somebody else's property seems like a certain way to engage in a much larger problem.
Parallax took the correct approach in solving this problem, plain and simple. It's rare that I get sideways with a customer, but we object to the comments about trying to "own" software in the way of Microsoft. What we're doing is exactly the opposite - do you see many open-source efforts from Microsoft?
Their efforts in that arena are self serving and inadequate. Let me give away something without any value to me, then let's pollute the notion by trying to point to that as important.
I would expect that Parallax will work on SPASM to de-duplicate code, specifically the PASM compilers will be merged. However, that isn't something you can wave a wand at and have it just work. The one bad thing about Roy announcing the C/C++ SPASM compiler is that it's really still in development. As a developer I know that you don't want to show an unfinished product to the consumer because they will give you all sorts of feedback that is unhelpful at that moment. You want to present a finished product that represents your vision of what you wanted to accomplish, then start taking requests.
Consider it like music, do you think that the great composers said "Hey, here's a rough draft of Concerto number 9"?
I think this thread is a great place for ideas, but leave the criticism at home.
Roy
Your fix worked for the issue I reported worked.
Before using your r28 version with the fix I tried running S2.spin through spin.exe and got the same error
I got with AD9833_3.spin. I was kind of surprised by that as I figured S2.spin would have been tried already.
I then produced S2.binary using your spin.exe and also using the Prop Tool v1.3
I then did a comparison using BeyondCompare my favorite comparing tool. http://www.scootersoftware.com/
It found no differences between what your spin.exe code produced and the Prop Tool v1.3
Great job so far, spin.exe works with everything I tried so far.
PS I haven't tried any of those compare tools, I like winwerge, I mostly use it to compare folders of sql server stored procedures, for doing quick compares I use notepad ++
The one bad thing about Roy announcing the C/C++ SPASM compiler is that it's really still in development. As a developer I know that you don't want to show an unfinished product to the consumer because they will give you all sorts of feedback that is unhelpful at that moment. You want to present a finished product that represents your vision of what you wanted to accomplish, then start taking requests.
I can give you our perspective on why it's being shared at this stage. First, it's a matter of supporting community involvement. Next, we hope to speed some of the bug fixes before Parallax validates this and stamps it as 100% compliant with the X86 version from which it was ported. We've got some developers who use this in their own products and we're hoping that their involvement in this public alpha (unofficial name) exposes any bugs. We could've done this behind closed doors, too.
Our Sr. Software Engineer Jeff Martin will do that after we get the PropGCC Eclipse-based GUI closer to beta release. We'll do the validation and verification before the beta PropGCC is released.
We are developing one compiler, the recent x86 to C conversion which Roy has completed.
Brad (BST) also wants our compiler as his is in some ways not validated by Parallax. And plus, how are we supposed to "open source" something we don't own? As you mentioned, Michael and Brad's compilers are owned by Michael and Brad, not Parallax. Giving away somebody else's property seems like a certain way to engage in a much larger problem.
Parallax took the correct approach in solving this problem, plain and simple. It's rare that I get sideways with a customer, but we object to the comments about trying to "own" software in the way of Microsoft. What we're doing is exactly the opposite - do you see many open-source efforts from Microsoft?
Ken Gracey
I agree with Ken, but I think it is important to make one point here - both Brad and Michael saved Parallax's bacon in many ways, because they provided features that Parallax either couldn't see the need for, or couldn't find the time to implement - like Linux and Mac support, preprocessor support, compiler listings, larger segment sizes and symbol tables, unused object/method elimination, blob extraction, other language support (Basic, C) etc, etc.
In part, these fantastic software efforts are what has driven much of the explosion in software innovation on the Propeller. Good as it is for many purposes, if we had all been limited to using only the Parallax Propeller tool then much of what we now take for granted would simply never have happened.
I wasn't aware that the GCC group were using yet another pasm compiler. How many compilers are Parallax developing?
You mean assembler, I assume.
The GNU binutils (which GCC relies on) comes with its own assembler, GAS. GAS supports features like separate code and data sections, LMM support, output to linkable ELF files, weak symbols, and various assembler directives which are not available in the PASM assembler built into Spin. Conversely, PASM is tightly integrated with Spin and has some features which Spin needs and which GAS lacks.
Theoretically, of course, it would be possible to extract PASM from Spin and enhance it with the features GCC needs. It's also theoretically possible to rewrite the Spin compiler so that it calls out to GAS (a separate program) to assemble DAT blocks, and to add the features that Spin needs to GAS. Perhaps one day one of those things will happen. For now, though, it was faster to use the GNU assembler with the GNU compiler and the Spin assembler with the Spin compiler. I can't speak for Parallax, but personally I think it's better to provide developers with two specialized tools now rather than one super-ultra swiss army knife tool that won't be available for many more months (and will cost money that could be spent on other tools).
I wasn't aware that the GCC group were using yet another pasm compiler. How many compilers are Parallax developing?
We have tried to have the compiler updated (PropTool) for so long that Michael Park (homespun) and Brad Campbell (bst) both wrote compilers, both free, and were being supported until something with Parallax seemed to happen. Now they are successful, Parallax shuns them and produces TWO of it's own.
Cluso,
If you meant PASM assemblers, there are quite a few of them. In addition to the ones in the Prop tool, PropGCC, BST and homespun there is one in Sphinx and the one that Bill Henning was developing. I also wrote a PASM assembler that I call "qasm" for "Quick Asembler". A PASM assembler is fairly easy to write. At this point, qasm is only 1400 lines of C code. It's probably the only PASM assembler that is currently capable of generating P2 code as well as P1 code. It uses a symbol definition file to describe the opcodes, so it is pretty easy to switch from P1 to P2 assembly. Once, we get more information on the P2 instruction set I should be able to update it in a matter of a few hours.
I haven't posted anything about qasm because it still needs a bit of work to handle PASM code contained in any Spin file. Basically, qasm reads a Spin file and translates the assembly code to longs. It's output is another Spin file without any assembly code. Most of the complexity in qasm is a result of having to handle constants that are defined as an arithmetic expression. The assembly part itself is pretty straightforward.
Uugh! All this talk of Eclipse, command lines, multiple tools, etc is a real turn-off to casual hobbyists like me
That said: I'm all in favour of any straight-forwardmechanism that allows me to control which objects to include. On the one hand I really like the simplicity of float: "C:\my\path\float32.spin", but I also see the problem of that if I want to share my code. I also don't like having to change an environment variable to achieve the same, so is there any reason why we can't specify (say) LIB: "C:\my\path\"?
BTW Roy: If you won't be supporting drive letters, how would I point to (say) \my\path ?
No good. Not all operating systems have drive letters.
In unix additional drives are "mounted" and they show up as regular directories somewhere in your file system.
As Phil says, it' not good to have OS features built into a language.
simonl,
For the command line executable compiler, it takes OS specific paths with the -I option (e.g. spin -I "C:\my\path\" mycode.spin).
For an IDE, there would be a configuration somewhere that would allow you to setup the path(s).
You won't need to worry about all the details we are discussing here. It's just stuff that allows advanced uses. When all the pieces are in place, you'll be able to just run an IDE and have an experience similar to what you have now with PropTool (actually, probably an even better experience in the long run).
As for the rest, who gives a rats about how many compilers/assemblers there are and who is supplying them as long as they work as advertised and are suitable for the task at hand and are free to download and use.
Comments
-Phil
Hi Roy,
Thanks for explaining. On the above two points, PASM should be allowed to be any size (e.g. 16Mb) to allow for LMM and XMM programs, and compiler listings are necessary if you want to use a debugger (e.g. to examine memory addresses). Look at the listings that both HomeSpun and BST can produce.
Ross.
The other thing required quite quickly - perhaps it is required by GCC, and I know Ross just asked for it, is larger pasm to support LMM/XMM. Maybe we require an new pasm instruction for this particular case. It is the jumps that cause the issue, where the address has to be held in the following long. Or a compiler directive.
I don't believe the GCC stuff needs this code to compile LMM/XMM output. Pretty sure they just produce output that GAS assembles into the binary that they run for that. The feature that has been requested of me for propgcc is the -c option from BSTC, that dumps out only DAT sections (compiled). I think it's only used for interfacing from GCC to pre-existing objects written in pasm.
I'm assuming for Ross's needs that I'll only need to have an option that allows for PASM code to be larger than 496 longs. I would expect his compiler to produce the LMM/XMM specific "opcodes" mixed into the PASM in the DAT section. The existing DAT block compile handles mixed pasm and data.
tdlivings,
Your reported bug is fixed with the current stuff up in the repository (r28).
Easy! So you can use all the OBEX Spin objects from any language! But even if that were not possible (which it is) why would you want to make everything dependent on propgcc when there is simply no need to do so? Why restrict all non-Spin development to the one tool chain?
BST and Homespun have been able to compile LMM programs for years now. All it takes is the ability to create PASM programs larger than 496 instructions, and have symbol tables larger than 1000 symbols (or whatever is the limit hardcoded in the Parallax compiler) - do that and you can compile LMM, SPIN and PASM programs all with one compiler. Or any other language you want just by using a suitable preprocessing step.
Too easy!
Ross.
P.S. I'm not knocking propgcc - but it is certainly a kind of overkill to have to use it as an assembler just because the standard Parallax assembler has arbitrary and unnecessary internal size limits!
Yes, that (plus the ability to have larger symbol tables) is a fair summary of the minimum requirement to support any language in conjunction with Spin. The propgcc route is of course another - but it is much more complex, partly because of all the other baggage you have to bring to the process of compiling programs with gcc.
That is kind of orthogonal to any LMM support as most PASM we want to pull out of existing Spin objects is not going to be LMM.
We only need the -c switch to do that.
Of course limits on the length of PASM and number of symbols should be removed. Actually having almost never used the Prop Tool I hadn't realized there were such hard limits.
It's one of those odd days that I find myself agreeing with you:)
Bugger! I must be wrong then!
Ross.
One of the projects this group has done as a collective is emulate an ancient processor called the Z80, and while this may seem a terribly old fashioned processor, it was at least designed to access 64k of memory easily. The propeller, on the other hand, modern chip that it is, has only 32k, and if you write a standard program and load up a spin processor and 7 cogs with their programs, you lose 14k of that 32k.
That is nearly half the available memory, and memory is very precious.
There are a number of solutions, one of which is to split the pasm and the spin code for objects and to store the pasm part as a separate file that is loaded off an SD card into a common 2k bank of ram and then into a cog. This process saves 12k of the 32k, and another 2k if you recycle the load buffer. But the catch is you need an SD driver which then uses up most of the 14k you just saved
I have been pondering what happens if you compile a standard spin program with lots of included objects, and it seems to be that the proptool leaves the 2k cog code scattered at random locations through memory.
I wonder if a compiler could at least group all the DAT code together at one location? It wouldn't matter if it was at the beginning or the end - all you would need to do is declare a variable just before the first DAT and that could become a pointer to the entire DAT group.
Would a compiled program know or care where DAT code was in hub?
What this could then mean is that if you have the first DAT declaration (which you could declare in the main program), and you were loading up n cogs, then you have a block of 2048*n k of hub space in a group that your program can access as a buffer (or whatever) once the cogs have all loaded.
I'm not sure if other compilers do this already, but it could be very handy to recycle that space as, say, an SD card buffer, or a buffer for a screen, or a font library or whatever. And I don't think it would change execution speed?
Maybe this is done already - any thoughts?
-Phil
Since Parallax is using 64k EEPROMs on the new boards, why not store a PASM overlay in the upper 32k, then load that dynamically. No RAM overhead penalty and no SD penalty.
We have tried to have the compiler updated (PropTool) for so long that Michael Park (homespun) and Brad Campbell (bst) both wrote compilers, both free, and were being supported until something with Parallax seemed to happen. Now they are successful, Parallax shuns them and produces TWO of it's own.
What gives here??? Is Parallax becoming a Microsoft (remember Netscape and Internet Explorer)???
-Phil
I had offered to write a SPIN compiler a short while ago, that's when Ken sent me an update of the then current state of their effort.
I wrote a compiler and opcode interpreter ~10 years ago for the company I was working for. Honestly I probably wouldn't have done the same thing today, but at the time I was reading the FLEX/YACC book and it scratched an itch.
--Perry
In order to facilitate GCC, which is a requirement, they needed to build a variant of GAS that supported PASM. That's my understanding of it.
Also, non of the existing compilers at the time were open source or willing to go open source.
You seem to really want Parallax to be bad guys in this, and they just aren't.
Roy
We are developing one compiler, the recent x86 to C conversion which Roy has completed.
Brad (BST) also wants our compiler as his is in some ways not validated by Parallax. And plus, how are we supposed to "open source" something we don't own? As you mentioned, Michael and Brad's compilers are owned by Michael and Brad, not Parallax. Giving away somebody else's property seems like a certain way to engage in a much larger problem.
Parallax took the correct approach in solving this problem, plain and simple. It's rare that I get sideways with a customer, but we object to the comments about trying to "own" software in the way of Microsoft. What we're doing is exactly the opposite - do you see many open-source efforts from Microsoft?
Ken Gracey
Microsoft || Open Source - Highlighted Projects
Their efforts in that arena are self serving and inadequate. Let me give away something without any value to me, then let's pollute the notion by trying to point to that as important.
I would expect that Parallax will work on SPASM to de-duplicate code, specifically the PASM compilers will be merged. However, that isn't something you can wave a wand at and have it just work. The one bad thing about Roy announcing the C/C++ SPASM compiler is that it's really still in development. As a developer I know that you don't want to show an unfinished product to the consumer because they will give you all sorts of feedback that is unhelpful at that moment. You want to present a finished product that represents your vision of what you wanted to accomplish, then start taking requests.
Consider it like music, do you think that the great composers said "Hey, here's a rough draft of Concerto number 9"?
I think this thread is a great place for ideas, but leave the criticism at home.
Your fix worked for the issue I reported worked.
Before using your r28 version with the fix I tried running S2.spin through spin.exe and got the same error
I got with AD9833_3.spin. I was kind of surprised by that as I figured S2.spin would have been tried already.
I then produced S2.binary using your spin.exe and also using the Prop Tool v1.3
I then did a comparison using BeyondCompare my favorite comparing tool.
http://www.scootersoftware.com/
It found no differences between what your spin.exe code produced and the Prop Tool v1.3
Tom
Thanks for reporting your results for S2.spin. It was on my list to check.
I also really like BeyondCompare. Another one I have used and like is UltraCompare (from the folks that make UltraEdit).
Roy
PS I haven't tried any of those compare tools, I like winwerge, I mostly use it to compare folders of sql server stored procedures, for doing quick compares I use notepad ++
I can give you our perspective on why it's being shared at this stage. First, it's a matter of supporting community involvement. Next, we hope to speed some of the bug fixes before Parallax validates this and stamps it as 100% compliant with the X86 version from which it was ported. We've got some developers who use this in their own products and we're hoping that their involvement in this public alpha (unofficial name) exposes any bugs. We could've done this behind closed doors, too.
Our Sr. Software Engineer Jeff Martin will do that after we get the PropGCC Eclipse-based GUI closer to beta release. We'll do the validation and verification before the beta PropGCC is released.
I agree with Ken, but I think it is important to make one point here - both Brad and Michael saved Parallax's bacon in many ways, because they provided features that Parallax either couldn't see the need for, or couldn't find the time to implement - like Linux and Mac support, preprocessor support, compiler listings, larger segment sizes and symbol tables, unused object/method elimination, blob extraction, other language support (Basic, C) etc, etc.
In part, these fantastic software efforts are what has driven much of the explosion in software innovation on the Propeller. Good as it is for many purposes, if we had all been limited to using only the Parallax Propeller tool then much of what we now take for granted would simply never have happened.
Ross.
You mean assembler, I assume.
The GNU binutils (which GCC relies on) comes with its own assembler, GAS. GAS supports features like separate code and data sections, LMM support, output to linkable ELF files, weak symbols, and various assembler directives which are not available in the PASM assembler built into Spin. Conversely, PASM is tightly integrated with Spin and has some features which Spin needs and which GAS lacks.
Theoretically, of course, it would be possible to extract PASM from Spin and enhance it with the features GCC needs. It's also theoretically possible to rewrite the Spin compiler so that it calls out to GAS (a separate program) to assemble DAT blocks, and to add the features that Spin needs to GAS. Perhaps one day one of those things will happen. For now, though, it was faster to use the GNU assembler with the GNU compiler and the Spin assembler with the Spin compiler. I can't speak for Parallax, but personally I think it's better to provide developers with two specialized tools now rather than one super-ultra swiss army knife tool that won't be available for many more months (and will cost money that could be spent on other tools).
Eric
If you meant PASM assemblers, there are quite a few of them. In addition to the ones in the Prop tool, PropGCC, BST and homespun there is one in Sphinx and the one that Bill Henning was developing. I also wrote a PASM assembler that I call "qasm" for "Quick Asembler". A PASM assembler is fairly easy to write. At this point, qasm is only 1400 lines of C code. It's probably the only PASM assembler that is currently capable of generating P2 code as well as P1 code. It uses a symbol definition file to describe the opcodes, so it is pretty easy to switch from P1 to P2 assembly. Once, we get more information on the P2 instruction set I should be able to update it in a matter of a few hours.
I haven't posted anything about qasm because it still needs a bit of work to handle PASM code contained in any Spin file. Basically, qasm reads a Spin file and translates the assembly code to longs. It's output is another Spin file without any assembly code. Most of the complexity in qasm is a result of having to handle constants that are defined as an arithmetic expression. The assembly part itself is pretty straightforward.
Dave
That said: I'm all in favour of any straight-forwardmechanism that allows me to control which objects to include. On the one hand I really like the simplicity of float: "C:\my\path\float32.spin", but I also see the problem of that if I want to share my code. I also don't like having to change an environment variable to achieve the same, so is there any reason why we can't specify (say) LIB: "C:\my\path\"?
BTW Roy: If you won't be supporting drive letters, how would I point to (say)
In unix additional drives are "mounted" and they show up as regular directories somewhere in your file system.
As Phil says, it' not good to have OS features built into a language.
For the command line executable compiler, it takes OS specific paths with the -I option (e.g. spin -I "C:\my\path\" mycode.spin).
For an IDE, there would be a configuration somewhere that would allow you to setup the path(s).
You won't need to worry about all the details we are discussing here.
Roy
As for the rest, who gives a rats about how many compilers/assemblers there are and who is supplying them as long as they work as advertised and are suitable for the task at hand and are free to download and use.
Cheers.