There's a much simpler way to get a C version of the Plain English compiler. It can already compile itself; so you don't need to translate the whole compiler to C. Just change it to produce C output instead of Intel opcodes and then run it on itself. Voila -- you'll have a C version. It may not be idiomatic C, but it will serve to bootstrap new platforms if necessary.
The reason that won't work for Heater is that the resulting C program (a) would still be a Windows program, dependent on the hundreds of Window's functions that are called upon to implement the routines in our standard library, and (b) would still be a GUI program (rather than a command-line "utility") with a whole lot of features that don't interest him.
The plan I've outlined above does, however, require exactly what you've suggested above -- changing the compiler to produce C output instead of Intel opcodes.
It's missing because the CAL-1000, the program we "bootstrapped" as described above, was not a fully functional compiler; it was mainly a very primitive text editor with just enough compiler to recompile itself. But it was enough so we could continue development exclusively in Plain English. So there never was a fully functional Plain English compiler written in another language.
Ah, but you just need enough compiler to be able to recompile itself (from a source file preferably). You don't need the text editor ... There are plenty of those around for pretty much any platform. At this point, things don't have to be pretty ... As long as there's a relatively minimal, but barely adequate code generator that can be easily reconfigured to put out text that can be further compiled or assembled by something else.
I hope one of the important points you're taking from this is that a compiler and an IDE should not be provided solely as a single IDE. You've broken up the source code wonderfully, break up your executables too. The single-executable-ide-compiler is cool and easy, and I suspect a lot of people really like that, so keep it. But also provide a standalone compiler. That alone will be a big improvement.
Ah, but you just need enough compiler to be able to recompile itself (from a source file preferably). You don't need the text editor ... There are plenty of those around for pretty much any platform. At this point, things don't have to be pretty ... As long as there's a relatively minimal, but barely adequate code generator that can be easily reconfigured to put out text that can be further compiled or assembled by something else.
I'm sorry, but I've lost track of exactly which "vision" for Plain English you've got in mind. This not-so-pretty, minimal compiler-sans-editor (that is nevertheless robust enough to recreate itself) --
1. What language is it written in?
2. What platform(s) does it run on?
3. What kind of code does it generate?
I proposed above (to Heater) a program, coded in C, that compiles and runs on anything that has a C compiler, and that produces C code as output from Plain English source (which would also compile and run on anything with a C compiler). Is that the same thing you're picturing?
I hope one of the important points you're taking from this is that a compiler and an IDE should not be provided solely as a single IDE. You've broken up the source code wonderfully, break up your executables too. The single-executable-ide-compiler is cool and easy, and I suspect a lot of people really like that, so keep it. But also provide a standalone compiler. That alone will be a big improvement.
When I'm writing code and the compiler finds an error, I want the system to position me, in the editor, on the offending line. This is relatively easy to achieve with an integrated development environment like ours, and it was one of the driving forces behind our choice of architecture. But I'm afraid my lack of experience with other systems is showing: How does a programmer in a non-integrated, command-line environment deal with compile-time errors? How are they reported? How does he get to the offending line?
I hope one of the important points you're taking from this is that a compiler and an IDE should not be provided solely as a single IDE. You've broken up the source code wonderfully, break up your executables too. The single-executable-ide-compiler is cool and easy, and I suspect a lot of people really like that, so keep it. But also provide a standalone compiler. That alone will be a big improvement.
When I'm writing code and the compiler finds an error, I want the system to position me, in the editor, on the offending line. This is relatively easy to achieve with an integrated development environment like ours, and it was one of the driving forces behind our choice of architecture. But I'm afraid my lack of experience with other systems is showing: How does a programmer in a non-integrated, command-line environment deal with compile-time errors? How are they reported? How does he get to the offending line?
The compiler reports the file and line number, and the user does whatever (s)he wants to get to the line and fix it. GCC prints out something like this:
The compiler reports the file and line number, and the user does whatever (s)he wants to get to the line and fix it.
You're kidding, right? People are actually willing to work like that? How do they ever get anything done? That's even worse than the compose-here-preview-there-come-back-here-to-make-corrections kind of editor on this (and most other) forums. What a world! Sixteen years into the 21st century and we're still wrestling with tools that are as inconvenient as they were back in the 1970's.
The compiler reports the file and line number, and the user does whatever (s)he wants to get to the line and fix it.
You're kidding, right? People are actually willing to work like that? How do they ever get anything done? That's even worse than the compose-here-preview-there-come-back-here-to-make-corrections kind of editor on this (and most other) forums. What a world! Sixteen years into the 21st century and we're still wrestling with tools that are as inconvenient as they were back in the 1970's.
Ah, the 70's But I think the problem with this is simply because it is GCC as I have used other C compiler IDEs that are far more friendly and professional. Still this comes back to PE outputting C source which is then compiled with GCC and there are only the two memory models that I am aware of, CMM and LMM, and from my pov these both have limitations. While it is good that it can compile straight COG PASM at times I find the CMM/LMM model awkward in that it consumes a lot of resources or is just plain slow. But it is an option and as mentioned would allow PE to be ported direct to other processors and platforms.
EDIT: However I would like to see it compile optimized Tachyon bytecodes, these I can run standalone or intermixed with an underlying Forth system.
The compiler reports the file and line number, and the user does whatever (s)he wants to get to the line and fix it.
You're kidding, right? People are actually willing to work like that? How do they ever get anything done? That's even worse than the compose-here-preview-there-come-back-here-to-make-corrections kind of editor on this (and most other) forums. What a world! Sixteen years into the 21st century and we're still wrestling with tools that are as inconvenient as they were back in the 1970's.
I don't disagree, it is ugly. But it's also perfectly functional. IF I want an IDE, then I will start an IDE and get the fully experience that you refer to. But personally, I think your IDE is awful. And there's nothing wrong with that; I simply want to do different things than you do. I am not 10 years old, and I am not just learning how to program. I do not need or want to be babied (aka: hindered).
And then there is also automation. Your IDE is interactive, so how can I setup a server to automatically trigger a build upon every commit if there is no command-line version of your compiler?
But personally, I think your IDE is awful. And there's nothing wrong with that; I simply want to do different things than you do. I am not 10 years old, and I am not just learning how to program. I do not need or want to be babied (aka: hindered).
It seems beauty really is in the eye of the beholder!
And then there is also automation. Your IDE is interactive, so how can I setup a server to automatically trigger a build upon every commit if there is no command-line version of your compiler?
I've proposed to Heater, a few posts back, the development of a stand-alone, command-line version of Plain English that will compile and run on any platform with a C compiler: it would be written entirely in C and would generate C as well. I haven't heard back from him yet. Perhaps you'd be interested in developing such a thing with me?
And then there is also automation. Your IDE is interactive, so how can I setup a server to automatically trigger a build upon every commit if there is no command-line version of your compiler?
I've proposed to Heater, a few posts back, the development of a stand-alone, command-line version of Plain English that will compile and run on any platform with a C compiler: it would be written entirely in C and would generate C as well. I haven't heard back from him yet. Perhaps you'd be interested in developing such a thing with me?
As much as it does interest me, I'm afraid my priority lies with PropWare still. I thought about volunteering earlier in the thread, because having Plain English on the Prop does sound very cool and I'd love to give a helping hand... but I have goals set for PropWare that need to get finished first.
I've proposed to Heater, a few posts back, the development of a stand-alone, command-line version of Plain English that will compile and run on any platform with a C compiler: it would be written entirely in C and would generate C as well. I haven't heard back from him yet.
I do appreciate the invitation.
I have to decline the offer. My life is full of other time consuming demands, at work and at home. If I find some time for myself I have a hundred other projects to be getting on with.
Perhaps sometimes, possibly, maybe, I have half-sensible suggestions as to how to promote "Plain English" and encourage wider adoption. Maybe right, maybe wrong.
That is the best I can do.
I have to leave it up to you as to how you proceed.
Come on @Heater. Just one more emulator. Just 25 Intel Opcodes needed to be simulated, a hook to emulate the needed windows API functions used and some way to extract the needed stuff out of a windows PE file...
OK external memory will be needed to run it, but CP/M did need memory also.
And you slowly have to get back to that emulator stuff. To get into the right mindset if there may be a P2 coming out. Just think about the poor ZOG freezing all the time.
Since @pullmoll vanished, you and @dr_acula are the last hope for CP/M on the P2.
1. What language is it written in?
2. What platform(s) does it run on?
3. What kind of code does it generate?
I'm really talking about two snapshots of the bootstrapping process. The first is written in some widely supported language. Could be Pascal or C or Forth or even COBOL. The defining criterion is that it accepts the minimal subset of Plain English necessary to compile a Plain English compiler. This could run on any platform large enough and fast enough for it to work (compile a Plain English compiler). It should generate some kind of simple source code that can be translated using an open-source tool into executable code. This could be a restrictive subset of C or Pascal or assembly. It could be Forth for that matter. It should be the same language used for this initial Plain English compiler.
The second snapshot is that of the first compiler written in Plain English that can compile itself into some sort of intermediate code that can, in turn, be processed to make it run on the target architecture ... standard bootstrapping. Main advantages of this scheme: You can take advantage of existing code optimizers. You can take advantage of existing I/O libraries, at least for the lower level operations that have equivalent functionalities to what you may want in Plain English. You can take advantage of existing code generators for multiple architectures. Main disadvantages: You're dependent on other people's code and designs for the "back end" and low level libraries. You're dependent initially on a "foreign" IDE. That can be fixed as soon as the bootstrapping has progressed to support the functionality you need for the IDE. Best to use some kind of abstract API layer that can be implemented on a wide variety of systems than making the API too close to some single API (like Windows). If you get too close to specific hardware, you may find that the next model, let alone some other vendors' system, requires too much interface code to be usable.
I'm really talking about two snapshots of the bootstrapping process...
That first step sounds a lot like what I've proposed today using C as both source and target. But while I've found a number of folks here who think this kind of re-work is essential to the future of Plain English, I haven't found anyone with enough time and interest to take it on. Yet. I think it best for an expert in C to do the C coding. I could probably stumble through it myself, but it would take much longer and I'm sure I wouldn't produce the kind of C the audience is expecting. (The last time I found myself forced to use C, many moons ago, I started by coding up macros to replace "{" and "}" with the words begin and end! ) It seems that only those who truly love a language can really speak it well.
That first step sounds a lot like what I've proposed today using C as both source and target. But while I've found a number of folks here who think this kind of re-work is essential to the future of Plain English, I haven't found anyone with enough time and interest to take it on. Yet. I think it best for an expert in C to do the C coding. I could probably stumble through it myself, but it would take much longer and I'm sure I wouldn't produce the kind of C the audience is expecting.
?
I've seen suggestions of targeting C as a High level Asm, but rewrite of the whole thing seems extreme, and I must have missed that suggestion.
If you generate C as HLA, no one even cares much about what that looks like, it just needs to compile on the target.
Quite a few systems go via intermediate languages these days.
IIRC, Xilinx redid their old ABEL PLD compilers, to generate Verilog.VHDL.
The output is not pretty, and certainly not something a human would write, but it does get ABEL source code into a lot more targets.
I've seen suggestions of targeting C as a High level Asm, but rewrite of the whole thing seems extreme, and I must have missed that suggestion.
Heater (and presumably others) think it would be good if the compiler was more portable -- compatible with Linux, at least -- and the usual way of making that happen is to (a) make the program a text-only command-line application so it can be used in a variety of ways and and workflows; and (b) write the thing in C so GCC can compile it and the open-source crowd coders who frequent GitHub and BitBucket can contribute to the further development of it. It was these open-source crowd coders whom I feared putting off with a non-standard style of C (not in the generated code, but in the source).
Personally, I don't like C and I don't like the command line and I don't like crowd coding. But I'm old enough to know that not everyone sees things the same way as everyone else. So the go-ahead on this particular idea depends on finding someone who does love C and the command line and crowd coding and who wants to see Plain English compatible with that environment -- wants it badly enough to translate 5,000 lines of code in their spare time!
Re self compiling, I have one working example I use, which is my home automation system programmed in C and running in CP/M on a Z80 emulation running on a FPGA. It is crazy, but it does actually work - I can stop the program running (^c), open the source in Wordstar, change a few lines, recompile (BDS C) and have the programming running again... all faster than a modern PC can boot up.
It isn't an IDE. And I don't think it would run fast enough on the Propeller, which is essentially a 20Mhz machine. The FPGA runs at 50Mhz, and it would be painfully slow on a real original 4Mhz Z80. And I am not sure the Propeller even has a simple text editor (maybe I'm wrong on that count).
So self compiling seems to me to go down a road that may involve a lot of work and might not produce much.
I'd be inclined to focus on more mundane things first. How do you do the simplest things in Plain English. Flashing a led, toggling some pins for serial comms, putting some text on a display.
Which Propeller languages have done those things. Spin =yes. I'd also say yes to C, as there are nifty conversion tools that have been written to convert C to Spin and vice versa. And I think Forth might tick those boxes too.
When we talk about Spin, it really is Spin and Assembly as most programs include some inline assembly. Sooner or later you have to get your hands dirty with assembly on the propeller. It isn't possible for instance to write a video driver in Spin.
So where do you start with Plain English? Bootstrap it from some simple commands, then write a self hosting compiler. Or start with code already done. How keen would you be to rewrite that serial port driver from scratch in Plain English?
Or do you compile Plain English down to some other language. Spin? LMM? Cog Assembly? Forth? C?
I can seem merits in all these and maybe it doesn't matter to the user. They write their code in Plain English and behind the scenes a compiler sorts it out.
Some years back I wrote a multi language IDE for the Propeller. You could have Basic, C, Spin, Assembly. It was a nice GUI front end for all the command line compilers for the Propeller, and so all you had to do was hit "compile". And then I took it a bit further, because at the time I wanted inline propeller in C, but C doesn't allow inline assembly. So I put all the assembly inside a comment block and then a pre-compiler took that and ran just the assembly through a command line propeller compiler, turned it into hex, and pasted that hex back into C as an array, which is something that is part of the C language.
So it can all be done. Maybe we brainstorm the merits of Spin, LMM, C and Forth?
The reason that won't work for Heater is that the resulting C program (a) would still be a Windows program, dependent on the hundreds of Window's functions that are called upon to implement the routines in our standard library, and (b) would still be a GUI program (rather than a command-line "utility") with a whole lot of features that don't interest him.
I don't particularly have a downer on GUI's or IDE's. In fact I use them every day. What I do campaign for is separating the compiler out into a stand alone command line program.
That gets you a long way down the road of making Plain English usable any platform, Windows , Mac, Linux, other.
It means Plain English can be used with the editor / IDE of the users choice. Everyone has their own favourites. Insisting they use the Plain English IDE in order to use the Plain English language will just put people off.
The ability to build a command line only Plain English compiler does not preclude also being able to build the same source code into a monolithic Plain English IDE, as you do now.
A classic example of this is Brad Campbell's excellent Spin compiler. Brad provided both BST, a full integrated compiler/editor/loader IDE, and BSTC a command line Spin compiler.
If such a command line compiler generated C or Forth or Spin bytecodes or even Propeller instructions it would allow people to use Plain English to create programs for the Propeller.
The issue of making the Plain English GUI usable on platforms other than Windows is an other story. Abstracting the higher levels of the program from the lower level drawing functions, as I and others have suggested, would allow interested programmers to create the low level layers for whatever platform they like.
You're kidding, right? People are actually willing to work like that? How do they ever get anything done? ... What a world! Sixteen years into the 21st century and we're still wrestling with tools that are as inconvenient as they were back in the 1970's.
Pretty much nobody works like that. They use IDE's and debuggers and whatever. One of the most popular IDE's in the world is MS Visual Studio. Sure enough VS consists of a GUI IDE and command line compilers for C, C++, C#, whatever.
Ha. Now I got you. You have to write the emulator in JavaScript and then port JavaScript to the Propeller and...OK. I shut up.
I already been suggested that Plain English emit Javascript. Getting Plain English to work in the browser would certainly get it in front of a lot of people. It would get a lot of exposure for this radically different style of programming.
So where do you start with Plain English? ... How keen would you be to rewrite that serial port driver from scratch in Plain English?
I think the real question is, How keen would other people be to write that serial port driver from scratch in Plain English? After studying up some more on the Propeller chip and Spin and Propeller Assembly and the various "objects" in the OBEX here, even I'm beginning to think that Plain English is a not a good fit! Here's why:
Plain English provides a natural and high-level interface to a machine primarily by burying the nasty details. For example, on Windows, this is the Plain English routine that adds one number to another:
To add a number to another number;
To increment a number by another number;
To bump a number by another number:
Intel $8B8508000000.
Intel $8B00.
Intel $8B9D0C000000.
Intel $0103.
The headers for this routine are English (it can be called three different ways), and the body is Intel machine code, in hex. Now a typical Plain English application on a desktop computer will have relatively few low-level routines -- almost all of which are generally useful like the one above -- but a whole lot of high-level routines (with all-Plain-English bodies) that make use of both the nasty low-level routines and other high-level routines. The ratio is probably a hundred to one or more: a hundred high-level, all-Plain-English routines for every low level routine with a machine code body.
And that's where desktop applications appear to differ from Propeller applications. Propeller applications, from what I've seen, tend to be very "bottom-heavy" -- they consist almost entirely of low-level routines that are specially designed to solve particular application problems. In fact, the few samples I've translated to Plain English have had high/low code ratios of about one in ten: ten low-level routines (with Spin or Assembler bodies) for each high-level routine.
And that's why I'm fast becoming convinced that while Plain English at the upper level (with a robust library of low-level routines) would make Propeller programming more friendly for the beginner, it probably wouldn't find much use among programmers who have real-world problems to solve.
And even if the high/low ratio was different, there would still be both performance and memory problems to overcome: all of the additional calls that Plain English generates, and all of stack space that's required by those (often recursive) calls, would be seriously limiting factors.
So where do you start with Plain English? ... How keen would you be to rewrite that serial port driver from scratch in Plain English?
I think the real question is, How keen would other people be to write that serial port driver from scratch in Plain English? After studying up some more on the Propeller chip and Spin and Propeller Assembly and the various "objects" in the OBEX here, even I'm beginning to think that Plain English is a not a good fit! Here's why:
Plain English provides a natural and high-level interface to a machine primarily by burying the nasty details. For example, on Windows, this is the Plain English routine that adds one number to another:
To add a number to another number;
To increment a number by another number;
To bump a number by another number:
Intel $8B8508000000.
Intel $8B00.
Intel $8B9D0C000000.
Intel $0103.
The headers for this routine are English (it can be called three different ways), and the body is Intel machine code, in hex. Now a typical Plain English application on a desktop computer will have relatively few low-level routines -- almost all of which are generally useful like the one above -- but a whole lot of high-level routines (with all-Plain-English bodies) that make use of both the nasty low-level routines and other high-level routines. The ratio is probably a hundred to one or more: a hundred high-level, all-Plain-English routines for every low level routine with a machine code body.
And that's where desktop applications appear to differ from Propeller applications. Propeller applications, from what I've seen, tend to be very "bottom-heavy" -- they consist almost entirely of low-level routines that are specially designed to solve particular application problems. In fact, the few samples I've translated to Plain English have had high/low code ratios of about one in ten: ten low-level routines (with Spin or Assembler bodies) for each high-level routine.
And that's why I'm fast becoming convinced that while Plain English at the upper level (with a robust library of low-level routines) would make Propeller programming more friendly for the beginner, it probably wouldn't find much use among programmers who have real-world problems to solve.
And even if the high/low ratio was different, there would still be both performance and memory problems to overcome: all of the additional calls that Plain English generates, and all of stack space that's required by those (often recursive) calls, would be seriously limiting factors.
That sounds very accurate. Any bare metal system needs a HAL. Doesn't matter if its a Propeller, Arduino, ARMv7 (Pi 2), or x86 machine. If you don't have an OS, you're going to want something else to act as your HAL. The only reason I'd ever use Plain English for bare-metal work is if someone else already wrote a HAL with all of the necessary objects that I planned to use - so that only the business logic was in English. For this reason, you might be better off providing a method of inline "assembly" where "assembly" is in fact whatever your target language is. For instance, if a Plain English compiler produces C output, then you would allow C to be injected into Plain English source code. If your output is assembled x86, then you would allow x86 instructions to be inserted in the form of hex numbers.
With this in mind, you could choose C++ as your assembled language and then leverage PropWare . That gives you a HAL with easy access to serial routines, a Pin class, etc etc.
As much as I love PropWare though, there's no reason you couldn't do this with any number of other languages/HALs for the Prop. Gather a bunch of different Spin files and then same thing could be accomplished. Tachyon, PBasic, etc all have their own HAL equivalents. You just need to have some way to access the HALs of these different systems through Plain English, so that you don't have to re-write them.
It''s true that if you look in most Propeller programs you will see a lot of low level code, "bottom-heavy" as you say.
That's because the Propeller does not have hardware devices like UART, SPI, I2C, USB etc etc as you find on many micro-controllers.
That is by design. The philosophy is that you get a blank canvas of 8 processing elements and you can program them to make whatever device you like. You can make weird and wonderful devices of your own.
But a well architected Propeller project will normally have a single "top level" object whose Spin code is above all that bit twiddling and just makes use of the service offered by the other COGs. 'serial.tx("A")' for example. Plain English could probably serve a language for such top level programming
People have created tons of low level drivers for all kind of things. The OBEX repository is full of them. Often the are mostly a PASM part that does all the serious work, and a simple collection of spin methods to interface to the user program. Like that serial.tx.
Sadly, when coming up with a new language like Plain English, none of all those drivers can be used to support it because they all have Spin interfaces.
It would have been better if all such drivers were written in two parts, a module containing the PASM code that gets run in a COG, and a module containing the Spin interfaces. These two modules communicating via "mail boxes", common areas of RAM when data is shared between the two worlds. Had such a mail box system been standardized right from the start then all those objects in OBEX would have PASM modules that could be used by other languages systems very easily. Over the years a few attempts have been made to create such a standard but they never got any traction.
If Plain English generated C code, or perhaps Propeller assembler, suitable for prop-gcc then it could make use of the growing collection of low level objects in the prop-gcc world.
That sounds very accurate. Any bare metal system needs a HAL...
I think that pretty much nails it. It seems that Plain English needs, not greener pastures, but larger ones where there's lots of room on top of the HAL to pile up the kind of deep Plain English "call graphs" that are typical of Plain English programs. I'm thinking a bare-metal Pi (or something like that) would be much better suited. Too bad that will take me back to interrupt land!
But I'd like to thank all of you here for your time and interest. I've learned a lot, and it's been a very pleasant experience (especially compared to the ones I've had on other forums). I'm sure the Propeller will continue to rattle around in my brain and if I ever come across an ideal application for it I'll be ready and I'll be back. Thanks again, everyone.
HAL? Bottom heavy code? The reason I mentioned Tachyon in the first place was because of the fast bytecode engine but also because a lot of HAL stuff has been done and is quite easy to add new stuff. The Tachyon code is not bottom heavy, it doesn't have to dedicate a PASM cog for every little timing critical driver, even 1-wire is handled directly at bytecode level and SD card "drivers" are high level as well since it uses SPIxx bytecode instructions.
The sample breakout game I attached earlier looks a bit more complicated than the PE version since it handles a lot of the little pixel details that might be hidden in PE.
So Gerry, I'd like to see PE as a suitable general-purpose (and commercial) programming front-end for Tachyon. What do you need?
Comments
The plan I've outlined above does, however, require exactly what you've suggested above -- changing the compiler to produce C output instead of Intel opcodes.
1. What language is it written in?
2. What platform(s) does it run on?
3. What kind of code does it generate?
I proposed above (to Heater) a program, coded in C, that compiles and runs on anything that has a C compiler, and that produces C code as output from Plain English source (which would also compile and run on anything with a C compiler). Is that the same thing you're picturing?
The compiler reports the file and line number, and the user does whatever (s)he wants to get to the line and fix it. GCC prints out something like this:
Ah, the 70's
EDIT: However I would like to see it compile optimized Tachyon bytecodes, these I can run standalone or intermixed with an underlying Forth system.
I don't disagree, it is ugly. But it's also perfectly functional. IF I want an IDE, then I will start an IDE and get the fully experience that you refer to. But personally, I think your IDE is awful. And there's nothing wrong with that; I simply want to do different things than you do. I am not 10 years old, and I am not just learning how to program. I do not need or want to be babied (aka: hindered).
And then there is also automation. Your IDE is interactive, so how can I setup a server to automatically trigger a build upon every commit if there is no command-line version of your compiler?
I've proposed to Heater, a few posts back, the development of a stand-alone, command-line version of Plain English that will compile and run on any platform with a C compiler: it would be written entirely in C and would generate C as well. I haven't heard back from him yet. Perhaps you'd be interested in developing such a thing with me?
1. Are you thinking this Tachyon-generating compiler would run on Windows?
2. Is there any documentation on how you've implemented Tachyon bytecodes on the Propeller?
3. Would you be interested in modifying our code to do this?
As much as it does interest me, I'm afraid my priority lies with PropWare still. I thought about volunteering earlier in the thread, because having Plain English on the Prop does sound very cool and I'd love to give a helping hand... but I have goals set for PropWare that need to get finished first.
I have to decline the offer. My life is full of other time consuming demands, at work and at home. If I find some time for myself I have a hundred other projects to be getting on with.
Perhaps sometimes, possibly, maybe, I have half-sensible suggestions as to how to promote "Plain English" and encourage wider adoption. Maybe right, maybe wrong.
That is the best I can do.
I have to leave it up to you as to how you proceed.
OK external memory will be needed to run it, but CP/M did need memory also.
And you slowly have to get back to that emulator stuff. To get into the right mindset if there may be a P2 coming out. Just think about the poor ZOG freezing all the time.
Since @pullmoll vanished, you and @dr_acula are the last hope for CP/M on the P2.
Just teasing you a bit.
Enjoy!
Mike
The second snapshot is that of the first compiler written in Plain English that can compile itself into some sort of intermediate code that can, in turn, be processed to make it run on the target architecture ... standard bootstrapping. Main advantages of this scheme: You can take advantage of existing code optimizers. You can take advantage of existing I/O libraries, at least for the lower level operations that have equivalent functionalities to what you may want in Plain English. You can take advantage of existing code generators for multiple architectures. Main disadvantages: You're dependent on other people's code and designs for the "back end" and low level libraries. You're dependent initially on a "foreign" IDE. That can be fixed as soon as the bootstrapping has progressed to support the functionality you need for the IDE. Best to use some kind of abstract API layer that can be implemented on a wide variety of systems than making the API too close to some single API (like Windows). If you get too close to specific hardware, you may find that the next model, let alone some other vendors' system, requires too much interface code to be usable.
Usually the editor is smart enough to parse that, and pop your cursor with the message, to give the illusion of 'integrated'
Real productivity comes from an IDE that includes a Simulator or Debug, that can single step and variable watch.
Can the PE IDE do that ?
I love the tease.
Did I really rag on you for being "MS" robots? I don't recall. Sorry if I did.
Realistically, I think I'm done with the emulation thing.
The 8080 emulator was just my way of learning PASM at the time.
The Z80 continuation was, well, a challenge.
Both of them were out of respect for Gary Kildall and his PL/M CP/M era.
ZOG was all about getting C/C++ code compiled with GCC running on the Prop. Since done much better of course by Catalina and prop-gcc.
Now a days, if I can't do it in Javascript I don't do it.
Ha. Now I got you. You have to write the emulator in JavaScript and then port JavaScript to the Propeller and...
OK. I shut up.
Mike
I've seen suggestions of targeting C as a High level Asm, but rewrite of the whole thing seems extreme, and I must have missed that suggestion.
If you generate C as HLA, no one even cares much about what that looks like, it just needs to compile on the target.
Quite a few systems go via intermediate languages these days.
IIRC, Xilinx redid their old ABEL PLD compilers, to generate Verilog.VHDL.
The output is not pretty, and certainly not something a human would write, but it does get ABEL source code into a lot more targets.
Personally, I don't like C and I don't like the command line and I don't like crowd coding. But I'm old enough to know that not everyone sees things the same way as everyone else. So the go-ahead on this particular idea depends on finding someone who does love C and the command line and crowd coding and who wants to see Plain English compatible with that environment -- wants it badly enough to translate 5,000 lines of code in their spare time!
It isn't an IDE. And I don't think it would run fast enough on the Propeller, which is essentially a 20Mhz machine. The FPGA runs at 50Mhz, and it would be painfully slow on a real original 4Mhz Z80. And I am not sure the Propeller even has a simple text editor (maybe I'm wrong on that count).
So self compiling seems to me to go down a road that may involve a lot of work and might not produce much.
I'd be inclined to focus on more mundane things first. How do you do the simplest things in Plain English. Flashing a led, toggling some pins for serial comms, putting some text on a display.
Which Propeller languages have done those things. Spin =yes. I'd also say yes to C, as there are nifty conversion tools that have been written to convert C to Spin and vice versa. And I think Forth might tick those boxes too.
When we talk about Spin, it really is Spin and Assembly as most programs include some inline assembly. Sooner or later you have to get your hands dirty with assembly on the propeller. It isn't possible for instance to write a video driver in Spin.
So where do you start with Plain English? Bootstrap it from some simple commands, then write a self hosting compiler. Or start with code already done. How keen would you be to rewrite that serial port driver from scratch in Plain English?
Or do you compile Plain English down to some other language. Spin? LMM? Cog Assembly? Forth? C?
I can seem merits in all these and maybe it doesn't matter to the user. They write their code in Plain English and behind the scenes a compiler sorts it out.
Some years back I wrote a multi language IDE for the Propeller. You could have Basic, C, Spin, Assembly. It was a nice GUI front end for all the command line compilers for the Propeller, and so all you had to do was hit "compile". And then I took it a bit further, because at the time I wanted inline propeller in C, but C doesn't allow inline assembly. So I put all the assembly inside a comment block and then a pre-compiler took that and ran just the assembly through a command line propeller compiler, turned it into hex, and pasted that hex back into C as an array, which is something that is part of the C language.
So it can all be done. Maybe we brainstorm the merits of Spin, LMM, C and Forth?
That gets you a long way down the road of making Plain English usable any platform, Windows , Mac, Linux, other.
It means Plain English can be used with the editor / IDE of the users choice. Everyone has their own favourites. Insisting they use the Plain English IDE in order to use the Plain English language will just put people off.
The ability to build a command line only Plain English compiler does not preclude also being able to build the same source code into a monolithic Plain English IDE, as you do now.
A classic example of this is Brad Campbell's excellent Spin compiler. Brad provided both BST, a full integrated compiler/editor/loader IDE, and BSTC a command line Spin compiler.
If such a command line compiler generated C or Forth or Spin bytecodes or even Propeller instructions it would allow people to use Plain English to create programs for the Propeller.
The issue of making the Plain English GUI usable on platforms other than Windows is an other story. Abstracting the higher levels of the program from the lower level drawing functions, as I and others have suggested, would allow interested programmers to create the low level layers for whatever platform they like. Pretty much nobody works like that. They use IDE's and debuggers and whatever. One of the most popular IDE's in the world is MS Visual Studio. Sure enough VS consists of a GUI IDE and command line compilers for C, C++, C#, whatever.
The idea was rejected.
Plain English provides a natural and high-level interface to a machine primarily by burying the nasty details. For example, on Windows, this is the Plain English routine that adds one number to another:
To add a number to another number;
To increment a number by another number;
To bump a number by another number:
Intel $8B8508000000.
Intel $8B00.
Intel $8B9D0C000000.
Intel $0103.
The headers for this routine are English (it can be called three different ways), and the body is Intel machine code, in hex. Now a typical Plain English application on a desktop computer will have relatively few low-level routines -- almost all of which are generally useful like the one above -- but a whole lot of high-level routines (with all-Plain-English bodies) that make use of both the nasty low-level routines and other high-level routines. The ratio is probably a hundred to one or more: a hundred high-level, all-Plain-English routines for every low level routine with a machine code body.
And that's where desktop applications appear to differ from Propeller applications. Propeller applications, from what I've seen, tend to be very "bottom-heavy" -- they consist almost entirely of low-level routines that are specially designed to solve particular application problems. In fact, the few samples I've translated to Plain English have had high/low code ratios of about one in ten: ten low-level routines (with Spin or Assembler bodies) for each high-level routine.
And that's why I'm fast becoming convinced that while Plain English at the upper level (with a robust library of low-level routines) would make Propeller programming more friendly for the beginner, it probably wouldn't find much use among programmers who have real-world problems to solve.
And even if the high/low ratio was different, there would still be both performance and memory problems to overcome: all of the additional calls that Plain English generates, and all of stack space that's required by those (often recursive) calls, would be seriously limiting factors.
That sounds very accurate. Any bare metal system needs a HAL. Doesn't matter if its a Propeller, Arduino, ARMv7 (Pi 2), or x86 machine. If you don't have an OS, you're going to want something else to act as your HAL. The only reason I'd ever use Plain English for bare-metal work is if someone else already wrote a HAL with all of the necessary objects that I planned to use - so that only the business logic was in English. For this reason, you might be better off providing a method of inline "assembly" where "assembly" is in fact whatever your target language is. For instance, if a Plain English compiler produces C output, then you would allow C to be injected into Plain English source code. If your output is assembled x86, then you would allow x86 instructions to be inserted in the form of hex numbers.
With this in mind, you could choose C++ as your assembled language and then leverage PropWare
As much as I love PropWare though, there's no reason you couldn't do this with any number of other languages/HALs for the Prop. Gather a bunch of different Spin files and then same thing could be accomplished. Tachyon, PBasic, etc all have their own HAL equivalents. You just need to have some way to access the HALs of these different systems through Plain English, so that you don't have to re-write them.
That's because the Propeller does not have hardware devices like UART, SPI, I2C, USB etc etc as you find on many micro-controllers.
That is by design. The philosophy is that you get a blank canvas of 8 processing elements and you can program them to make whatever device you like. You can make weird and wonderful devices of your own.
But a well architected Propeller project will normally have a single "top level" object whose Spin code is above all that bit twiddling and just makes use of the service offered by the other COGs. 'serial.tx("A")' for example. Plain English could probably serve a language for such top level programming
People have created tons of low level drivers for all kind of things. The OBEX repository is full of them. Often the are mostly a PASM part that does all the serious work, and a simple collection of spin methods to interface to the user program. Like that serial.tx.
Sadly, when coming up with a new language like Plain English, none of all those drivers can be used to support it because they all have Spin interfaces.
It would have been better if all such drivers were written in two parts, a module containing the PASM code that gets run in a COG, and a module containing the Spin interfaces. These two modules communicating via "mail boxes", common areas of RAM when data is shared between the two worlds. Had such a mail box system been standardized right from the start then all those objects in OBEX would have PASM modules that could be used by other languages systems very easily. Over the years a few attempts have been made to create such a standard but they never got any traction.
If Plain English generated C code, or perhaps Propeller assembler, suitable for prop-gcc then it could make use of the growing collection of low level objects in the prop-gcc world.
I think that pretty much nails it. It seems that Plain English needs, not greener pastures, but larger ones where there's lots of room on top of the HAL to pile up the kind of deep Plain English "call graphs" that are typical of Plain English programs. I'm thinking a bare-metal Pi (or something like that) would be much better suited. Too bad that will take me back to interrupt land!
But I'd like to thank all of you here for your time and interest. I've learned a lot, and it's been a very pleasant experience (especially compared to the ones I've had on other forums). I'm sure the Propeller will continue to rattle around in my brain and if I ever come across an ideal application for it I'll be ready and I'll be back. Thanks again, everyone.
gerry.rzeppa@pobox.com
The sample breakout game I attached earlier looks a bit more complicated than the PE version since it handles a lot of the little pixel details that might be hidden in PE.
So Gerry, I'd like to see PE as a suitable general-purpose (and commercial) programming front-end for Tachyon. What do you need?