Prof_Braino, I have looked very closly at SD caching, and had started on a test system of my own before I realized Bill was doing something similar. The problem I have is that while I don't need a large data throughput, I do need to carefully control latency. The advantage EEPROM has over SD is the SD paging mechanism. You pretty much have to read 512 bytes at a time even if you only need 16 in the middle of the page. At 20 MHz a SD card page fault takes about 250 microseconds to resolve, and in a page thrashing situation or major context switch you pretty much have to be prepared to wait it out for every 512 bytes of code. Let's say the Prop needs to serivice the ENC28J60 ethernet stack. That will probably involve switching in 8 to 16K of code -- especially if it's compiled to LMM -- and then switching the other code it displaced when the ethernet chip is serviced. This could very easily end up taking tens of milliseconds. And when it gets sluggish it can require some serious profiling to figure out exactly why.
By contrast, while my scheme is fundamentally slower it can also turn on a dime, cache arbitrarily small bits of code without loading any more than necessary, and do it all with very compact code that packs a lot more functionality in few bytes with things like single bytecode complex string operations implemented in PASM. Finally, for those situations where you really do need more speed, after the system boots it can copy itself to a faster form of memory such as SPI RAM or even a wide second Prop based interface and switch to that.
My experience from years of doing the kind of systems I do is that only a small fraction of the code needs to be fast, but that code really needs to be reliably fast. With Windmill a single keyword either puts such code permanently in RAM or swaps it into an L1-like cache, while the code that does not need to be fast is run straight out of the EEPROM consuming no Hub RAM at all and itself having very reliable, if ploddy, timing.
Actually, writing a PASM assembler on the propeller would be the easiest of those four. There is a 1:1 correspondence from mnemonics to opcodes. Spin would probably be next, and BASIC would probably be about the same if it targeted the spin interpreter. C would be the hardest.
I am looking at this from the perspective of ONE Propeller chip on board. Now if somebody comes up with a concoction of, lets say four Propeller chips, hooked in such a manner that you have the capability of programming the chips as ONE, and not each one separately, then you have a completely different scenario, and I would say "I am all for it!". But till then, it is an impractical proposition.
Ray
Default is one prop chip. default options are 0) normal EEPROM, 1) increased EEPROM 2) SD
The SD option is for example the spineret configuration
Impractical or not, we have it and it works just great. We can use a serial terminal, (emulator program or VT100 series hardware), VGA and key board directly on demo board or C3 or Hive, etc; or over Ethernet when using spineret/wiz8100 and telnet, with next version supporting html.
I saw this thread and i thought i would just put my two cents in:)... As some of you know, i have been working on a OS (More like a program launcher) for the C3, which is better than half way to completion. I have also been working on a C3 programming language called HOLL-E(Highly Objective Learning Language). This would be well suited to the C3, which has a ton of on-board memory configurations. Basically, it will just be a very simple beginners language that will enable the user to write a few lines of code to do things that would have been a little harder under normal conditions. I don't think people will be developing huge fast programs on it, but it will be nifty for the C3 newbie. People will write the program out on the C3, which will be initially stored in the C3 RAM. Once the user thinks that the program is ready, the Propeller will "Compile" it and save the program data onto a SD file AND the raw un-compiled program saved to another. The individual will then have to load up the "Interpreter" program, which will then run the selected compiled program. The machine will probably be only able to run a few thousand instructions per second, but things like video will be running at full speed(Obviously)... I still have yet to actually sit down and work on HOLL-E, but i have most of it already designed in my head:) So yeah, i think light development is not only possible on the Prop, but also fun and informative
... You pretty much have to read 512 bytes... 250 microseconds to resolve ... ENC28J60 ethernet stack. That will probably involve switching in 8 to 16K of code -- especially if it's compiled to LMM -- and then switching the other code it displaced when the ethernet chip is serviced.
I agree with bulk of your comment, we noticed similar. The only difference is that we don't do LMM or automatic paging. Less overhead, smaller code, much faster. Its a different set of constraints than others appear to be comfortable with, but it definitely can be made to work, and is simply another alternative Your scheme sounds cool, I will be interested do see how you do it.
You know, it's funny. The original Apple ][ shipped with something like 8Kb RAM, and it could be programmed on. Seems to me, with our nice SD card storage, and EEPROM programming right on the Prop can be done fairly well to how it was done then.
And there is always a PC for the bigger projects, or where too many resources are required.
For a single prop, it makes sense to break things into chunks, and offer a few modes. One could be like Bean's BASIC. It's actually good on a single prop, capable of a lot of things, despite limited program space. So that could be one mode.
Another might be "edit mode", where you use a whole prop to just build code. Launch that, edit, then when it's time to build, write the data to SD, launch the bits needed to build, then launch into what was built. Hit RESET, and you are back to "edit mode" in a pinch, with the whole cycle not taking too long. Some creative use of the EEPROM would handle the state details...
I'd just like to say that there is nothing "primitive" about text based or command line tools.
Again agreed. I'm not talking about command line tools. I know that underneath the snazzy IDE, Xcode is doing all the preprocessing, compiling, and linking with command line tools. But I really appreciate the code completion, syntax highlighting, and other bells and whistles. They help me be a more productive programmer. Although I have been known to invoke gcc directly from time to time. The thing that originally drew me to OS X almost ten years ago was the fact that is was built on Unix. The first thing I did when I got a Mac running OS X was to get into the Terminal and start playing around.
I've used Eclipse briefly and I share your assessment. The open-source movement has plenty of benefits but beautiful, functional, well-designed user interfaces are not one of the common ones.
I'm surprised that you say "I think it has merit in the hobbyist sector". I would have though exactly the opposite. A hobbyist or casual programmer or beginner can be well served by an IDE where you open a window, type the program and hit the "run" button.
(I was in a hurry when I posted this morning so I wasn't as clear as I would have liked to be. We were getting ready to hit the road to visit family.) When I said hobbyist what I really meant was the hard-core propeller programmers like the ones on this forum. The ones writing compilers, coming up with new memory models, emulating other processors, and the like. The ones using the Propeller largely because it's a new, fun, and exciting microprocessor that at the same time is fueling a lot of nostalgia-based computing. And I don't mean that in a dismissive way. I'm in awe of the talent on this forum.
What I was thinking of is the fact that Parallax is putting a lot of effort into increasing the propeller's use in industry. If Ken Gracey came into my boss' office and demoed an on-board programming environment that looked like it would be at home on a Commodore 64, he would be thanked for his time and shown the door.
If Ken Gracey came into my boss' office and demoed an on-board programming environment that looked like it would be at home on a Commodore 64, he would be thanked for his time and shown the door.
Precisely. It's for this very reason that I hope Chip doesn't waste his time with an on-chip dev system for the Prop 2. There are more important things to work on if Parallax Semiconductor is to be taken seriously.
"I think it is a great idea, but at the same time I do not believe it is a practical proposition."
You guys are funny. Reminds me of "Interesting, Orville; but it will never fly"
Indeed! And there is nothing wrong with a little reverse psychology here. Tell people on this forum that something is impossible and soon along will come a solution.
But it is not a simple problem. Ok, assume someone writes/creates a text editor, and it can be a GUI one or a text one - it does not matter. So leave that to one side, let's think about a command line program. It can be written in any language. It takes a text file from an SD card (or eeprom or flash if you like), and it saves a binary file.
As pence128 points out, a pasm compiler might be the easiest.
Maybe Basic to PASM might be the next one?
Spin is hard. There have been other threads on this forum talking about an open source spin compiler. I'm not sure where that ended up but I think it got bogged down in the parser that you need to untangle commands in multiple nested brackets.
As for C, I thought it might be easy but as Ross has pointed out over on the Catalina thread, behind the scenes Catalina is using BST to compile spin type tokens into pasm, and we don't have access to the source, so compiling C might be as hard as compiling spin.
There is nothing impossible here though. I once wrote a two pass compiler that took a custom language that looked like a schematic (simple logic gates from the 74xx family) and converted it into Z80 assembly. I guess that gave me an idea how complex compilers can be.
The nested bracket is possibly one of the big problems to solve. Prop Basic is a simpler language in that many instructions translate directly to pasm code, so maybe PropBasic might be the language to look at here?
Then you have to ask what language do you write your compiler in? I'm a Basic programmer at heart but I'd have to lean towards Catalina C here because so much of the background work is already there - eg opening a text file on an sd card, reading in lines, and closing is code that we already have. PropBasic could be a real possibility. Last time I checked it didn't have many string functions, but if strings have been added then it would make things a lot easier.
As for C, I thought it might be easy but as Ross has pointed out over on the Catalina thread, behind the scenes Catalina is using BST to compile spin type tokens into pasm, and we don't have access to the source, so compiling C might be as hard as compiling spin.
Just a couple of small corrections - Catalina uses homespun, not bstc. I used to support bstc as well, but I decided I didn't need to support two SPIN compilers to do the same job.
Also, Catalina does not compile Spin to PASM. It compiles C to PASM. Spin is used only in the various target files. The main reason for this is to avoid the need to have dozens and dozens of precompiled targets lying around (i.e. at least one for each supported platform).
However, for self-hosted development, where you are by definition compiling only for a single target, it woud be better to simply have a precompiled binary target - this would correspond roughly to what in GNU is called crt0.
So for self-hosted Catalina development you don't need a SPIN compiler, you just need a PASM assembler.
Now look. You didn't have to bring that up It seems both EMACS and VI have gotten friendlier over the years.
Yes, both have definitely gotten much better over the years - vi has gotten better at editing text files, and emacs has gotten better at making coffee, polishing your car, ironing your socks and keeping your accounts in order - but it's still lousy at editing text files!
The nested bracket is possibly one of the big problems to solve.
What is the problem with nested brackest in expressions?
Jack Crenshaw gives a nice simple explanation and examples of how to do it here http://compilers.iecc.com/crenshaw/
Resulting in a single pass compiler for a simple Pascal like language.
It's about the only treatise on compiler writing I've ever understood!
Thanks Ross for clarifying those points. It is most helpful to know more about the inside of a compilation process. I would imagine that one of the first steps is to take a high level language and to unwrap all the things in brackets to work out which order to do things. Maybe somewhere along the way a language gets converted into tokens of some sort? I don't know if this is how a C compiler works on the inside? Then convert to assembly language?
Are you saying Ross that much of this already exists in catalina, and all you need is a pasm assembler? ie something that takes the text of "rdlong a,b" and converts it to the appropriate hex or binary values?
Thanks Ross for clarifying those points. It is most helpful to know more about the inside of a compilation process. I would imagine that one of the first steps is to take a high level language and to unwrap all the things in brackets to work out which order to do things. Maybe somewhere along the way a language gets converted into tokens of some sort? I don't know if this is how a C compiler works on the inside? Then convert to assembly language?
Yes - lcc parses the entire C program into an abstract syntax tree - which is similar to what you've probably seen for a simple expression parser - e.g. an expression such as a * (b - c) becomes ...
*
+--^--+
| |
a -
+--^--+
| |
b c
.. but a whole lot more complicated, since it includes not only expressions, but all other language syntax elements (function calls, if statements, loops etc). After the tree is built, lcc traverses the entire tree - essentially bottom-up - calling the code generator to emit the appropriate code for each node in the tree (e.g. in the above tree the nodes a, b, c would correspond to loading values into registers, and * and - would correspond to emitting mul and sub instructions.
Are you saying Ross that much of this already exists in catalina, and all you need is a pasm assembler? ie something that takes the text of "rdlong a,b" and converts it to the appropriate hex or binary values?
Yes - for the above example, lcc parses the C source, builds the tree and then traverses it - the Catalina code generator would emit instructions as follows (assuming the prop had a mul instruction):
rdlong r1,@b
rdlong r2,@c
sub r1,r2
rdlong r3,@a
mul r3,r1
Then all it has to do is bind it (to resolve library function calls etc) and then assemble the final result.
What I was thinking of is the fact that Parallax is putting a lot of effort into increasing the propeller's use in industry. If Ken Gracey came into my boss' office and demoed an on-board programming environment that looked like it would be at home on a Commodore 64, he would be thanked for his time and shown the door.
Then for the professional applications wait for the Prop2, this will give enough space to have a pretty good looking WIMP GUI OS in hub mem, and still leave enough left over for the data, and a simple command processor. Back in the mid 90s I wrote a simple GUI based OS that looked modern, though only took 18KB of ram on the x86-IA32, and it ran in PMode I did this just to prove I could (I was actually targeting under 12KB of RAM required though for that I would have to sacrifice some of the nice aesthetics), and it had its own bitmapped font.
Windows, Linux and Mac systems certainly provide a better environment for software development. However, it would be interesting to build tools that would allow developement directly on the Prop. Part of the problem that I see is that individual components have been done, such as the Sphinx compiler or a nice text editor, but they depend on specific drivers, and they can only be run within that environment. It would be nice if we could develop a standard driver interface so that programs that run in one environment could be easily ported to other environments.
It would be good to have a text editor that can run with a keyboard and video driver, but also operate with a serial console interface. The Sphinx compiler requires features provided by the Sphinx OS. It would be nice if it's I/O was generalized a bit more so it would operate with other OS'es. Or more precisely, it would be good if all OS'es used the same programming interface for console and file I/O.
I have developed some simple tools for program development under spinix. There is an "ed" utility that does some simple line editing. The current version is quite limiting, and I have a newer version in C that supports more of the "ed" commands. I also added a mode where it prints out the lines around the current pointer after each command. Eventually, I want to write a "vi" based on the code from "ed".
spinix also contains a Spasm assembler that will convert Spin assembly instructions into an executable binary file. There is a hello.spa source file that implements a "Hello World" in Spasm.
Finally, I have done some work on a Spin compiler. My approach is to convert Spin into Spasm, which can then be assembled into Spin bytecodes. The compiler is written in C, and it can compile some simple Spin programs. If I ever complete the C version I'll port it to Spin so it can run directly on the Prop.
Sphinx provides an excellent base concept. I did some work on generalised drivers and Drac has done some excellent work with catalina and dynamic loading of cojects. Kye has a great SD driver. We just need to tie all these things together. Drac is working on a prop GUI too and it looks great.
Dave, I'd dispute that GUI systems are inherently better; as I posted earlier I felt much more productive using a very efficient window-toggling screen editor in DOS even though I had to drop out of the editor to compile and test. It was fast, responsive, and allowed me to every meaningful thing I can do in the GUI without my fingers leaving the keyboard.
Although it will start with a simple CLI I anticipate building a very nice text based editing environment for Windmill. A big advantage of a thoroughly bottom-up Forth-like language is that you are never really debugging a huge pile of code all at once; you work in small blocks, and when you finish them they are very thoroughly finished. You are rarely ever actually editing anything more than a few pages long. And the amount of text I get on a hacked 7 inch LCD -- 28 lines of 60 characters -- is about what I see of actual code in the VB6 GUI at any given time (or at least it was until I got my 1080p monitor, and still I tend now to leave the GUI un-maximized so I can see other apps while I work).
And it is possible to build a surprisingly responsive full-screen editor that runs over a serial link, so the UI could be on the PC. This will be the second default mode of Windmill after the CLI, since a full screen ANSI text editor running at 19.2 Kbaud can do anything you could do with actual direct memory mapped RAM in the 1980's. (I used such a system for internet access, with Lynx as web browser, over a dialup modem through Procomm Plus until late 1999.)
You know, it's funny. The original Apple ][ shipped with something like 8Kb RAM, and it could be programmed on. Seems to me, with our nice SD card storage, and EEPROM programming right on the Prop can be done fairly well to how it was done then.
And there is always a PC for the bigger projects, or where too many resources are required.
For a single prop, it makes sense to break things into chunks, and offer a few modes. One could be like Bean's BASIC. It's actually good on a single prop, capable of a lot of things, despite limited program space. So that could be one mode.
Another might be "edit mode", where you use a whole prop to just build code. Launch that, edit, then when it's time to build, write the data to SD, launch the bits needed to build, then launch into what was built. Hit RESET, and you are back to "edit mode" in a pinch, with the whole cycle not taking too long. Some creative use of the EEPROM would handle the state details...
This is where I find the idea of on-prop programming to be the most interesting, is in the realization of some sort of retro-inspired computer. Not for any kind of professional application, but I think there's potentially high value for an educational purpose. There is something to be said about a system small enough that a single person can see an understand the entire workings of it. That kind of exposure I think can really get newcomers really engaged in learning about computing.
I wonder if I went back, to the time I was beginning to learn, and all I had in front of me was a windows system (do they even ship with a version of BASIC anymore?), I wonder if I would have been quite as excited to learn about computing technology? I wonder if the fact that our computers and our XBOXes are bearing more similarities with each generation, if such an 'old school inspired' platform wouldn't do some things to spark some imaginations where they aren't now with the modern systems/IDEs/etc.
I agree with this, though I will say that a Linux system can spark some of that same excitement. On Linux, you get a ton of dev tools, the OS is malleable, and there is emulation, virtual machines, etc... Deffo the learning environment, if not the production building environment.
The old machines were something one person could understand, and that's got it's appeal. Clearly a batch of us still enjoy that scale. I've been very large scale now, multi-CPU NUMA systems, boatloads of RAM, lots 'o users, remote display, network, you name it. A lot of that's gone now, or relegated to the data center, leaving us with mostly bland environments. In my spare time, I like smaller scale computing now. Things come full circle.
I think my friends abroad would disagree, depending on what they experienced in their regions, but I have to say the Apple was the best of the lot then. It shipped with most basic tools in ROM, and it just begged to be played with, added on to, very nicely done. The other machines had various stronger attributes, but no where near the hackability that one did.
Seems to me, something like that, not necessarily on chip for Prop II, but doable now, and with Prop II would make a lot of sense, particularly, if it could take add-ons in a sane way, like that machine did.
Well, the nice thing about text interfaces is there are no input state changes from keyboard to mouse. That's got some distinct advantages.
I find for authoring things, just knocking out the input, keyboard only rocks!
I find twiddling around nice in the GUI.
Frankly, I would blend the two!! Run it text mode, but offer enough character density such that windows and a basic mouse could be used, and life would be pretty darn golden.
I'm thinking a nice 80x50, or larger to start. A nice font, like the old Apple "Mouse Text" would be a great blend of the two, making a lot of people happy input and work-flow wise, while being fairly reasonable on overall screen resources required to get it done.
A 16 bit character definition table would allow for the usual 8 bits of text, while also allowing for graphics windows on the screen where needed. The alternative to that would be to do it Chip's way, and use the tile address / palette system found in the reference Parallax drivers for a very capable display. One could implement windows, graphics, text, and back-store with that driver, or a tile / character driver, depending.
I think my friends abroad would disagree, depending on what they experienced in their regions, but I have to say the Apple was the best of the lot then.
I would argue that Apple is the best of the lot now. Xcode and the Cocoa frameworks are a tremendous development environment and come free with every Mac along with Ruby, gcc, & perl. Plenty of hacking tools.
Linux...Deffo the learning environment, if not the production building environment.
That's odd. All of my professional development has been done on Linux since about 2000.
Frankly, I would blend the two!! Run it text mode, but offer enough character density such that windows and a basic mouse could be used, and life would be pretty darn golden.
I think you have just described Borland Turbo Pascal from back in the DOS days. That was great. The idea lives on in the Free Pascal IDE http://en.wikipedia.org/wiki/Free_Pascal
Yeah, depends on the niche. In mine, Linux isn't a option, unless you've got very serious problems that could benefit from what a UNIX can do. Most people don't, and even when they do, they will more often than not, just pay to kludge and feel good about it.
In very general terms, I think my statement is accurate, particularly for the up and comer looking for a great set of tools. Lots can be done. Some things can't, or are expensive though. Depends. Because of that, I more or less live in Windows. Sometimes I get to employ a Mac, or Linux, and all those UNIX skills come back. Funny too. Even when one forgets half of it, what's left still rocks hard.
I do not mean to slight Linux, or UNIX in general though, and the why on that should be a happy diversion one of these days, another thread, probably. If my day job was doing this kind of stuff, I would be on a Linux box full time, stuffing the rest into VMs, where I had to deal with them.
We say that it is difficult, it can't be done and so on... but Heater mentioned Turbo Pascal. The v3 is a39kbytes executable. The editor is in there, the compiler is in there and the runtime is in there!. Of course the PC has another 500 kbytes available... but that editor was fast, all keyboard shortcuts that I haven't forgot (and used it some 20 years ago!)... well I knew only a handful but still we are hardcore users not afraid of a text bw screen and a keyboard. Writing an assembler, even a two pass assembler is quite easy... I even solved the bracket problem...! (that was a difficult one!)... but expression parsers are still mystery to me If someone wants I can write a LMM-PASM compiler (in LMM of course) .... we only have to agree in which resources can/have to be used...
We do not even have to load the program into memory.... we only need a symbol table and a tokenized version... both can go to disk if any driver allows for more than 2 open files, simultaneously!
Re: GUI vs Text.
Frankly, I would blend the two!! Run it text mode, but offer enough character density such that windows and a basic mouse could be used, and life would be pretty darn golden.
I don't know if this counts, but propforth has plans to use the spineret to serve HTML5 web pages as the development GUI. The HTML pages will be able to execute forth routines. For example, the forth debugger will send the status of the stack and/or memory dumps to the web page at the end (next) of each or selected words. The assembler debugger can do the same at assembler routines. Also, any custom words can be called. The user can arrange the browser windows on the dispaly (of the netbook/PC/Apple) any way desired. OF course, this requires a separate computer, but it only needs a browser, and not a specific IDE. So while its still text based, the window functionality is achived via the browser.
As much as I tend to go limp with apathy over any on-chip dev tools, you've perked my interest with the HTML5 stuff! Why not combine the old with the new? It makes perfect sense. Please keep us informed of your progress!
I don't know if this counts, but propforth has plans to use the spineret to serve HTML5 web pages as the development GUI. The HTML pages will be able to execute forth routines. For example, the forth debugger will send the status of the stack and/or memory dumps to the web page at the end (next) of each or selected words. The assembler debugger can do the same at assembler routines. Also, any custom words can be called. The user can arrange the browser windows on the dispaly (of the netbook/PC/Apple) any way desired. OF course, this requires a separate computer, but it only needs a browser, and not a specific IDE. So while its still text based, the window functionality is achived via the browser.
Is anybody else trying this method?
This sounds pretty cool! And, because you're connected by ethernet, you don't even have to be near the machine you're debugging! I can sit in my comfortable chair with my MacBook on my lap and debug my Propeller board over on my desk or in my lab. Maybe I need to try PropForth!
Comments
By contrast, while my scheme is fundamentally slower it can also turn on a dime, cache arbitrarily small bits of code without loading any more than necessary, and do it all with very compact code that packs a lot more functionality in few bytes with things like single bytecode complex string operations implemented in PASM. Finally, for those situations where you really do need more speed, after the system boots it can copy itself to a faster form of memory such as SPI RAM or even a wide second Prop based interface and switch to that.
My experience from years of doing the kind of systems I do is that only a small fraction of the code needs to be fast, but that code really needs to be reliably fast. With Windmill a single keyword either puts such code permanently in RAM or swaps it into an L1-like cache, while the code that does not need to be fast is run straight out of the EEPROM consuming no Hub RAM at all and itself having very reliable, if ploddy, timing.
Actually, writing a PASM assembler on the propeller would be the easiest of those four. There is a 1:1 correspondence from mnemonics to opcodes. Spin would probably be next, and BASIC would probably be about the same if it targeted the spin interpreter. C would be the hardest.
Default is one prop chip. default options are 0) normal EEPROM, 1) increased EEPROM 2) SD
The SD option is for example the spineret configuration
Impractical or not, we have it and it works just great. We can use a serial terminal, (emulator program or VT100 series hardware), VGA and key board directly on demo board or C3 or Hive, etc; or over Ethernet when using spineret/wiz8100 and telnet, with next version supporting html.
I agree with bulk of your comment, we noticed similar. The only difference is that we don't do LMM or automatic paging. Less overhead, smaller code, much faster. Its a different set of constraints than others appear to be comfortable with, but it definitely can be made to work, and is simply another alternative Your scheme sounds cool, I will be interested do see how you do it.
And there is always a PC for the bigger projects, or where too many resources are required.
For a single prop, it makes sense to break things into chunks, and offer a few modes. One could be like Bean's BASIC. It's actually good on a single prop, capable of a lot of things, despite limited program space. So that could be one mode.
Another might be "edit mode", where you use a whole prop to just build code. Launch that, edit, then when it's time to build, write the data to SD, launch the bits needed to build, then launch into what was built. Hit RESET, and you are back to "edit mode" in a pinch, with the whole cycle not taking too long. Some creative use of the EEPROM would handle the state details...
Absolutely. We need look no further than the never-ending vi vs. emacs debate.
Again agreed. I'm not talking about command line tools. I know that underneath the snazzy IDE, Xcode is doing all the preprocessing, compiling, and linking with command line tools. But I really appreciate the code completion, syntax highlighting, and other bells and whistles. They help me be a more productive programmer. Although I have been known to invoke gcc directly from time to time. The thing that originally drew me to OS X almost ten years ago was the fact that is was built on Unix. The first thing I did when I got a Mac running OS X was to get into the Terminal and start playing around.
I've used Eclipse briefly and I share your assessment. The open-source movement has plenty of benefits but beautiful, functional, well-designed user interfaces are not one of the common ones.
(I was in a hurry when I posted this morning so I wasn't as clear as I would have liked to be. We were getting ready to hit the road to visit family.) When I said hobbyist what I really meant was the hard-core propeller programmers like the ones on this forum. The ones writing compilers, coming up with new memory models, emulating other processors, and the like. The ones using the Propeller largely because it's a new, fun, and exciting microprocessor that at the same time is fueling a lot of nostalgia-based computing. And I don't mean that in a dismissive way. I'm in awe of the talent on this forum.
What I was thinking of is the fact that Parallax is putting a lot of effort into increasing the propeller's use in industry. If Ken Gracey came into my boss' office and demoed an on-board programming environment that looked like it would be at home on a Commodore 64, he would be thanked for his time and shown the door.
-Phil
Indeed! And there is nothing wrong with a little reverse psychology here. Tell people on this forum that something is impossible and soon along will come a solution.
But it is not a simple problem. Ok, assume someone writes/creates a text editor, and it can be a GUI one or a text one - it does not matter. So leave that to one side, let's think about a command line program. It can be written in any language. It takes a text file from an SD card (or eeprom or flash if you like), and it saves a binary file.
As pence128 points out, a pasm compiler might be the easiest.
Maybe Basic to PASM might be the next one?
Spin is hard. There have been other threads on this forum talking about an open source spin compiler. I'm not sure where that ended up but I think it got bogged down in the parser that you need to untangle commands in multiple nested brackets.
As for C, I thought it might be easy but as Ross has pointed out over on the Catalina thread, behind the scenes Catalina is using BST to compile spin type tokens into pasm, and we don't have access to the source, so compiling C might be as hard as compiling spin.
There is nothing impossible here though. I once wrote a two pass compiler that took a custom language that looked like a schematic (simple logic gates from the 74xx family) and converted it into Z80 assembly. I guess that gave me an idea how complex compilers can be.
The nested bracket is possibly one of the big problems to solve. Prop Basic is a simpler language in that many instructions translate directly to pasm code, so maybe PropBasic might be the language to look at here?
Then you have to ask what language do you write your compiler in? I'm a Basic programmer at heart but I'd have to lean towards Catalina C here because so much of the background work is already there - eg opening a text file on an sd card, reading in lines, and closing is code that we already have. PropBasic could be a real possibility. Last time I checked it didn't have many string functions, but if strings have been added then it would make things a lot easier.
Just a couple of small corrections - Catalina uses homespun, not bstc. I used to support bstc as well, but I decided I didn't need to support two SPIN compilers to do the same job.
Also, Catalina does not compile Spin to PASM. It compiles C to PASM. Spin is used only in the various target files. The main reason for this is to avoid the need to have dozens and dozens of precompiled targets lying around (i.e. at least one for each supported platform).
However, for self-hosted development, where you are by definition compiling only for a single target, it woud be better to simply have a precompiled binary target - this would correspond roughly to what in GNU is called crt0.
So for self-hosted Catalina development you don't need a SPIN compiler, you just need a PASM assembler.
Ross.
Yes, both have definitely gotten much better over the years - vi has gotten better at editing text files, and emacs has gotten better at making coffee, polishing your car, ironing your socks and keeping your accounts in order - but it's still lousy at editing text files!
Ross.
Indeed. vi has grown up to this http://cream.sourceforge.net/features.html which is about as "GUI- WISIWIG-User friendly" as you could hope for.
Dr_A,
What is the problem with nested brackest in expressions?
Jack Crenshaw gives a nice simple explanation and examples of how to do it here http://compilers.iecc.com/crenshaw/
Resulting in a single pass compiler for a simple Pascal like language.
It's about the only treatise on compiler writing I've ever understood!
Are you saying Ross that much of this already exists in catalina, and all you need is a pasm assembler? ie something that takes the text of "rdlong a,b" and converts it to the appropriate hex or binary values?
* +--^--+ | | a - +--^--+ | | b c.. but a whole lot more complicated, since it includes not only expressions, but all other language syntax elements (function calls, if statements, loops etc). After the tree is built, lcc traverses the entire tree - essentially bottom-up - calling the code generator to emit the appropriate code for each node in the tree (e.g. in the above tree the nodes a, b, c would correspond to loading values into registers, and * and - would correspond to emitting mul and sub instructions. Yes - for the above example, lcc parses the C source, builds the tree and then traverses it - the Catalina code generator would emit instructions as follows (assuming the prop had a mul instruction):Then all it has to do is bind it (to resolve library function calls etc) and then assemble the final result.
Ross.
It would be good to have a text editor that can run with a keyboard and video driver, but also operate with a serial console interface. The Sphinx compiler requires features provided by the Sphinx OS. It would be nice if it's I/O was generalized a bit more so it would operate with other OS'es. Or more precisely, it would be good if all OS'es used the same programming interface for console and file I/O.
I have developed some simple tools for program development under spinix. There is an "ed" utility that does some simple line editing. The current version is quite limiting, and I have a newer version in C that supports more of the "ed" commands. I also added a mode where it prints out the lines around the current pointer after each command. Eventually, I want to write a "vi" based on the code from "ed".
spinix also contains a Spasm assembler that will convert Spin assembly instructions into an executable binary file. There is a hello.spa source file that implements a "Hello World" in Spasm.
Finally, I have done some work on a Spin compiler. My approach is to convert Spin into Spasm, which can then be assembled into Spin bytecodes. The compiler is written in C, and it can compile some simple Spin programs. If I ever complete the C version I'll port it to Spin so it can run directly on the Prop.
Dave
Although it will start with a simple CLI I anticipate building a very nice text based editing environment for Windmill. A big advantage of a thoroughly bottom-up Forth-like language is that you are never really debugging a huge pile of code all at once; you work in small blocks, and when you finish them they are very thoroughly finished. You are rarely ever actually editing anything more than a few pages long. And the amount of text I get on a hacked 7 inch LCD -- 28 lines of 60 characters -- is about what I see of actual code in the VB6 GUI at any given time (or at least it was until I got my 1080p monitor, and still I tend now to leave the GUI un-maximized so I can see other apps while I work).
And it is possible to build a surprisingly responsive full-screen editor that runs over a serial link, so the UI could be on the PC. This will be the second default mode of Windmill after the CLI, since a full screen ANSI text editor running at 19.2 Kbaud can do anything you could do with actual direct memory mapped RAM in the 1980's. (I used such a system for internet access, with Lynx as web browser, over a dialup modem through Procomm Plus until late 1999.)
This is where I find the idea of on-prop programming to be the most interesting, is in the realization of some sort of retro-inspired computer. Not for any kind of professional application, but I think there's potentially high value for an educational purpose. There is something to be said about a system small enough that a single person can see an understand the entire workings of it. That kind of exposure I think can really get newcomers really engaged in learning about computing.
I wonder if I went back, to the time I was beginning to learn, and all I had in front of me was a windows system (do they even ship with a version of BASIC anymore?), I wonder if I would have been quite as excited to learn about computing technology? I wonder if the fact that our computers and our XBOXes are bearing more similarities with each generation, if such an 'old school inspired' platform wouldn't do some things to spark some imaginations where they aren't now with the modern systems/IDEs/etc.
The old machines were something one person could understand, and that's got it's appeal. Clearly a batch of us still enjoy that scale. I've been very large scale now, multi-CPU NUMA systems, boatloads of RAM, lots 'o users, remote display, network, you name it. A lot of that's gone now, or relegated to the data center, leaving us with mostly bland environments. In my spare time, I like smaller scale computing now. Things come full circle.
I think my friends abroad would disagree, depending on what they experienced in their regions, but I have to say the Apple was the best of the lot then. It shipped with most basic tools in ROM, and it just begged to be played with, added on to, very nicely done. The other machines had various stronger attributes, but no where near the hackability that one did.
Seems to me, something like that, not necessarily on chip for Prop II, but doable now, and with Prop II would make a lot of sense, particularly, if it could take add-ons in a sane way, like that machine did.
Well, the nice thing about text interfaces is there are no input state changes from keyboard to mouse. That's got some distinct advantages.
I find for authoring things, just knocking out the input, keyboard only rocks!
I find twiddling around nice in the GUI.
Frankly, I would blend the two!! Run it text mode, but offer enough character density such that windows and a basic mouse could be used, and life would be pretty darn golden.
I'm thinking a nice 80x50, or larger to start. A nice font, like the old Apple "Mouse Text" would be a great blend of the two, making a lot of people happy input and work-flow wise, while being fairly reasonable on overall screen resources required to get it done.
A 16 bit character definition table would allow for the usual 8 bits of text, while also allowing for graphics windows on the screen where needed. The alternative to that would be to do it Chip's way, and use the tile address / palette system found in the reference Parallax drivers for a very capable display. One could implement windows, graphics, text, and back-store with that driver, or a tile / character driver, depending.
I would argue that Apple is the best of the lot now. Xcode and the Cocoa frameworks are a tremendous development environment and come free with every Mac along with Ruby, gcc, & perl. Plenty of hacking tools.
That's odd. All of my professional development has been done on Linux since about 2000.
I think you have just described Borland Turbo Pascal from back in the DOS days. That was great. The idea lives on in the Free Pascal IDE http://en.wikipedia.org/wiki/Free_Pascal
Re: odd
Yeah, depends on the niche. In mine, Linux isn't a option, unless you've got very serious problems that could benefit from what a UNIX can do. Most people don't, and even when they do, they will more often than not, just pay to kludge and feel good about it.
In very general terms, I think my statement is accurate, particularly for the up and comer looking for a great set of tools. Lots can be done. Some things can't, or are expensive though. Depends. Because of that, I more or less live in Windows. Sometimes I get to employ a Mac, or Linux, and all those UNIX skills come back. Funny too. Even when one forgets half of it, what's left still rocks hard.
I do not mean to slight Linux, or UNIX in general though, and the why on that should be a happy diversion one of these days, another thread, probably. If my day job was doing this kind of stuff, I would be on a Linux box full time, stuffing the rest into VMs, where I had to deal with them.
We do not even have to load the program into memory.... we only need a symbol table and a tokenized version... both can go to disk if any driver allows for more than 2 open files, simultaneously!
I don't know if this counts, but propforth has plans to use the spineret to serve HTML5 web pages as the development GUI. The HTML pages will be able to execute forth routines. For example, the forth debugger will send the status of the stack and/or memory dumps to the web page at the end (next) of each or selected words. The assembler debugger can do the same at assembler routines. Also, any custom words can be called. The user can arrange the browser windows on the dispaly (of the netbook/PC/Apple) any way desired. OF course, this requires a separate computer, but it only needs a browser, and not a specific IDE. So while its still text based, the window functionality is achived via the browser.
Is anybody else trying this method?
As much as I tend to go limp with apathy over any on-chip dev tools, you've perked my interest with the HTML5 stuff! Why not combine the old with the new? It makes perfect sense. Please keep us informed of your progress!
-Phil
This sounds pretty cool! And, because you're connected by ethernet, you don't even have to be near the machine you're debugging! I can sit in my comfortable chair with my MacBook on my lap and debug my Propeller board over on my desk or in my lab. Maybe I need to try PropForth!