dMajo said...
BTW: @Chip, how is the instruction fetching of the new PropII made? It will be still necessary to interpose a line between the modifier and the modified code lines?
Chip Gracey said...
Yes, when you modify an instruction ahead, you must execute one in the middle ...
Thank goodness this "feature" will propagate to the P2. It's what makes coroutine implementation drop-dead simple!
-Phil
@PhiPi: could you explaint better? I don't get the meaning of your words. I tought that if you modify the next following line and are able to execute it immediately is better. Than if you need you can still put some line(s) between. One thing is you can do, other is you must do. What the benefit of "must" in this case?
> I'm not going to get started on this one, but really, why on earth would Parallax switch to making compilers for OS's that are
> simply a geek fad that will be soon outdated and then to keep up with technology will have to get as stuffed up as Windows?
If the compiler is written in C or C++, it could be recompiled (the compiler) on almost any platform. Then you need a loader that is platform-dependant but only in the part where you open and close and write to the comm-port. The IDE needs to hook to the two programs. IDEs that run on different platforms are available, for free. ImageCraft's ICCProp almost does it that way. And a lot of other compiler do work that way. IDE and compiler are completely different things.For bells and whistles and better integration, the IDE could read information (variable size, data size, code size etc.) from a map file.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Nick Mueller said...
> I'm not going to get started on this one, but really, why on earth would Parallax switch to making compilers for OS's that are
> simply a geek fad that will be soon outdated and then to keep up with technology will have to get as stuffed up as Windows?
If the compiler is written in C or C++, it could be recompiled (the compiler) on almost any platform. Then you need a loader that is platform-dependant but only in the part where you open and close and write to the comm-port. The IDE needs to hook to the two programs. IDEs that run on different platforms are available, for free. ImageCraft's ICCProp almost does it that way. And a lot of other compiler do work that way. IDE and compiler are completely different things.For bells and whistles and better integration, the IDE could read information (variable size, data size, code size etc.) from a map file.
Nick
The IDE can also interact with the compiler and the loader if these are made as libraries (DLL) the same as if they were built-in (they can share variables, classes ...). Moreover as DLLs they can be used by other apps (IDEs)
microcontrolled: When you say "OS's that are simply a geek fad" I presume you are referring to Apple's OS X, Linux and such. I have to say that "FAD" is a rather strange way to describe systems that can trace their linage back to 1969 en.wikipedia.org/wiki/Unix.
Seen it that light it looks like Windows is the "FAD" albeit not a geek one.
Nobody is suggesting creating tools that don't work on Windows. There are plenty of ways to create applications that run multiple platforms nowadays. Even if you have to do it in Java or C# (Gak and gak). Just means having to avoid using features that are unique to a single system.
Our favourite example around here is the BST tool. Runs everywhere important.
It's about time the world started to think seriously about weaning itself of off it's dependence on a single company for it's computing infrastructure. I find it a bizarre and unhealthy situation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That's exactly where the OS-dependency starts. The compiler has to be a command-line tool. So you could use it without IDE. Such a compiler could even work under (Free-)DOS, CP/M or whatever. As long as someone is willing to take the effort to compile for that platform (and make a few adjustments by platform-specific #defines).
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
No need for #defines. If your compiler is written in standard C/C++ or Pascal, or ADA or whatever it is quite possible that the effort required to compile for a different platform amounts to copying the source to the platform and hitting the compile button in a different IDE. There really is little excuse for such programs to be platform specific nowadays.
When it comes to the IDE's and GUI's making them cross platform can be a bit more tricky. However there are a number of cross platform libraries. I'm developing a graphical application now using Qt. So far everything I have wanted to do with it is working on Windows, Linux, Mac without a single change to my code. Including 3D rendering.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In theory: Yes. In praxis: No. Because you might have to switch compilers and then there's a chance you have to make adjustments (size of types etc.). But nothing impossible.
The Prop II might have enough RAM to let run a SPIN-compiler written in C. And here, you'll need your defines, because of lack of file-handling.
> Oh for the love of pete, don't say that. You'll get them all excited.
I didn't write that by chance!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
But that's my point. Qt exists and it works. As do many other cross-platform libraries starting from the standard C libs upwards. They can be full of #ifdefs and whatever spaghetti but as an application author one does not have to see it or care about it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But you missed mine.
I was talking about an compiler, and not an IDE. It's no wonder that you don't need #defines when you are using an platform-independent tool. But if you write an platform-independent tool ... #defines
And if you intend to use Qt for writing a command-line compiler ... well, doesn't make much sense and won't run on DOS or CP/M or the Prop.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Nick, Maybe I'm tired but I'm still missing your point.
The way I see it is that if you are writing a compiler it is basically just another program that reads it's input from a file or files and writes it's output to some other file. Perhaps writing and reading some intermediate files along the way, object files say.
So as long you have the standard set of open, close, read, write etc functions available and some means of getting command line arguments in then the compiler itself can be compiled on whatever platform with no #ifdefs. So there I have it a platform-independent tool with no #ifdefs.
Now if your compiler actually targets different architectures x86, ARM, PowerPC etc then that is different problem. One that can also be solved with no #ifdefs. But what we are talking about here is a Prop Spin/PASM compiler so no problem anyway.
As it happens Qt has a core library that is totally independent of the GUI stuff. So it is quite possible to write command line only programs in Qt. In fact I have used this for a server application where Qt takes care of all the cross platform networking stuff, threading, XML parsing, etc etc.
I might not want to use it for a compiler but no reason not to consider it.
Given that one can compile ADA under CP/M I think Spin/PASM would be a piece of cake [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
>heater: Given that one can compile ADA under CP/M I think Spin/PASM would be a piece of cake [noparse]:)[/noparse]
Well, the gauntlet certainly has been thrown down there!
Ok, command line interface. Very simple program - text file input and text file output. CP/M can certainly handle ADA and Pascal and other languages that are perfect for text file in and text file out.
I guess what might be unknown is what the actual program looks like. Is any of the spin/pasm compiler open source?
I cannot see the point of having an IDE and tools mask programmed in ROM as there are so many negatives to that, plus the extended time it will take to ensure there are no bugs in it, and, if there are bugs, we're stuck with them forever.
Far better I would say to develop the tools to go on SD Card, USB stick or whatever and boot the tools at start-up. Any usably decent development system is going to need the boot media for storing and transferring files on anyway.
There can be a Windows utility which loads the required files to whatever that media is, and it's easy enough to let the user decide which pins are used for what ( mouse, keyboard, TV, VGA etc ) in the process. Far better IMO than a ROM system which dictates how everything has be configured up-front.
There's also no limit to what the 'embedded IDE' can do. It can be expanded, added to and developed as time goes on. People can extend that as they wish if Parallax document how or people figure it out.
The key arguments for this path are - shorter time to market for the Prop II as it only needs the mechanism working not the embedded IDE, and the IDE can be developed in parallel or after.
I can understand the dream of an OLPC-style embedded development platform but, whether it boots from ROM or boots from external media, it's not really any different at the end of the day. If it were Flash not ROM I might feel differently, but it's not and doesn't ever seem likely to be.
On cross-platform development ...
Should be easy enough as some have said. The IDE on whatever OS can be as complicated or as simple as anyone chooses to make it; NotePad style or full-blown Visual Studio style. I don't buy into the argument that Windows gets in the way of creating a decent IDE as that depends entirely on what one wants and sets out to achieve.
My own NotePad style IDE's calling compilers ( though that rather under-sells what they actually do ) work unchanged on everything from 95 to Windows 7 and I had very few GUI or Windows API issues ( the jump from 98 to XP brought the main issues, but rather minor ). I could have added eye-candy, done cleverer things and increasingly tied myself into potential compatibility issues but didn't want to and what I have is credible and usable enough, and importantly isn't tied to anything which will likely only work on one version of Windows. If others want a better IDE then they can write one.
The only essential is that the command line compiler can handle what's thrown at it and delivers all that an IDE needs to use it. Each has to handle file paths and files slightly differently but that is a relatively minor issue. The majority of a compiler should be platform independent by nature, and not constrained or affected by OS GUI issues.
Downloading has issues because that can vary from platform to platform but a three way split solves that; IDE, compiler, downloader.
> So as long you have the standard set of open, close, read, write etc functions available and some means of getting command line ...
For example, a '\n' is represented differently on different platforms. If the CrLf-scheme (from Win) is to be used, you have to open files binary under *NIX and do your own reading. Other/elder compilers may have arranged functions in different header files. 16 bit compilers (for smaller OSes) have different types-sizes then compilers of bigger OSes that do have 32 bit compilers. Little-endian CPUs vs. Big-Endian CPUs will make odd results when you emmit the 32bit SPIN-codes or constants.
Platforms without an OS (like the Prop) won't allow you do do piping (pass parameters to and from the compiler).
Error-codes from the OS ("disk full", "file not found", ...) are different.
And so on and so on ...
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
@heater: Sorry, I thought that Linux systems originated around year 2000 at the earlyest. In that case I thought that it was simply something people where going crazy about just because it wasn't windows and you didn't have to buy an expensive Mac to use it. Of course the interface is not as "good looking" as Windows and maybe not as slick, so only computer-working people use it. Another reason for this is that the average person dosn't use it because there are no commercialy availible machines that have it preinstalled, so you have to download it yourself. This is why I phrased it as a "geek fad". Sorry for my thought that this was a newer thing and not an original.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Computers are microcontrolled.
@Nick: All very true if you are working down at that level. There is no reason you can't build your app on top of a shim like Qt core or some other library. Or in Java or C# or whatever.
I have worked on a C programs for embedded systems that had no problem emitting binary structures containing a mess of bits, bytes and words on big and little endian processors with no #ifdefs required. Also using different memory alignment restrictions on different processors.
16 bit vs 32 bit I admit may be an issue for raw C code.
Anyway my main point is that creating console only programs, even a compiler, that works on many platforms is not a major issue in this day and age. Been there done that.
@Hippy. I concur. I'm all for the Prop being able to support it's own development environment I just don't see the point of having it the ROM. However small it may be there must be something more generally useful to put in that space. After all the idea is to sell millions of chips, only a hand full of them are going to be used to develop on.
Did anyone actually say "Windows gets in the way of creating a decent IDE" I must have missed that. Problem is what it does is get in the way of me being able to use said decent IDE, which is a shame especially if it's author would like to have everyone use it. In that way there is no decent Windows based IDE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
microcontrolled said...
@heater: Sorry, I thought that Linux systems originated around year 2000 at the earlyest. In that case I thought that it was simply something people where going crazy about just because it wasn't windows and you didn't have to buy an expensive Mac to use it. Of course the interface is not as "good looking" as Windows and maybe not as slick, so only computer-working people use it. Another reason for this is that the average person dosn't use it because there are no commercialy availible machines that have it preinstalled, so you have to download it yourself. This is why I phrased it as a "geek fad". Sorry for my thought that this was a newer thing and not an original.
The Linux kernel was developed by Linus Torvalds in 1991, although full-blown Linux took another couple of years. I think I was playing with it in 1995, loaded onto my PC from 14 floppy disks.
Lots of commercial systems for "average people" are shipped with Linux, and it's used on a lot more servers than MS software, because of the higher performance and reliability.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Microcontrolled, having to download it yourself is a result of legal efforts, including covenants, ownership of core intellectual components, and specifications, used to prevent computer manufacturers and application developers from building things in a way that would permit choice in the marketplace.
The fact that most people acquire a computer with something already loaded is an economy of scale. Nothing nefarious there. The fact that it is almost always one specific OS is. Microsoft has aggressive legal arrangements in place, or uses financial means to basically prevent computers from being shipped with open code, and that's why Linux is most often downloaded.
If you can't open it, and that means being able to examine all elements of it, you really don't own it, and are forced to trust others, whether or not that is a problem for you. This is a matter of computing ideology for some people, and it's important like other ideologies are important for how the vision of them, and the competition between them shapes much of the world.
Most rather ordinary people don't get overly concerned about these things, but they do benefit from the efforts of those that do. This is true in life for many things, not just computers. Your civics work this way as well, where it's not skill, but your own personal freedoms and life choices in play, not what your hardware may or may not be doing. The dynamic is the same.
A discussion like this isn't exactly productive, as in the product of it does something immediate. That makes it "thick" or "heady", or "lofty" in ways that are distracting, if taken to extremes. Be wary of that. However, it is productive in that core ideas like these, can and do govern many things, with results higher up in life potentially being troublesome, should some ideologies dominate, without consideration given to others.
An example that you can easily relate to would be your home schooling. The fact that you get to do that is the product of a discussion like this, where the product of it is law that does not overly constrain your parents. Had that discussion gone another way, or those who believe in the value of that kind of education not participated, the choice may well not be on the table for you today. Many of us believe in those kinds of choices, and have spoken where necessary to preserve them.
It is my opinion that all of us share some burden in this, where if we don't speak, we end up being spoken for, and that comes around full circle to the context in this thread, where we are simply speaking for what should be obvious reasons now. Agreement is not necessary, but mutual consideration is. It is good to know where others stand on these things. Sometimes it brings insight to participate, other times just frustration. No getting around that.
Maybe that helps some to clarify some of this thread.
Well. The first ever Linux kernel was given to the world in 1991.
The GNU software including the GCC compiler, that has always been a major part of a usable Linux operating system was started in 1984.
The first proper Windows OS, NT 3.1, was launched in 1993.
("Proper" as in comparable to Unix and other real operating systems).
Whilst Linux shared no code with the original Unix it obviously follows in the Unix tradition hence I said "linage back to 1969".
People do not go crazy about Linux "because it wasn't Windows". (Well perhaps some do but never mind). If you want to understand what the motivation for Linux and GNU is you should read the history here http://www.gnu.org/gnu/thegnuproject.html When Richard Stallman talks about the "software-sharing community" of the 1970's it may remind you of the Propeller community here.
"Of course the interface is not as "good looking" as Windows". Ooo now I'm steaming[noparse]:)[/noparse] I think the KDE desktop on my Debian box is much better looking than the XP I have in virtual machine here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't understand where the negatives are with an IDE in ROM, other than the time consideration. On that matter, it's not like there is a zero sum game. If the design of the chip is holistic, then the time taken is the time taken, right? Those tools must be realized anyway, why not in the context of the chip? That's how I see it, but the more important thing is these other negatives.
If something like this is available on the Propeller, how does that imply being inclusive? It's not like it would be THE set of development tools, is it? Chip mentioned the life boat analogy. So then, one option would be to use Propellers to develop for Propellers. Another would be to use the kinds of tools we use now to develop for Propellers, and another will be tools not yet realized. Doesn't this marginalize the negatives, given people can and will choose how they feel they must, and with the assumption that the on chip tools are enough to boot strap subsequent efforts?
(BTW: This is a really great thread all. Some excellent discussion has taken place.)
BradC said...
I don't particularly agree that the IDE, compiler and loader are decoupled though. The IDE has some very, very deep hooks into the compiler to allow access to the symbol table so that when you click on a symbol in the editor you get some information about it down the bottom (plus a few other funky background bits). As I had no experience previously providing cross platform tools, I wrote the loader first as a test, then the compiler and then the IDE followed. They are still published as separate tools as I find it useful to have command line tools, but in the IDE they are as tightly coupled as you could get. There is no way to separate out the compiler and substitute it for example.
I guess it would have been more accurate to say "extract the compiler and loader from the IDE as command line tools." A good IDE should be very intimate with the compiler in order to provide features that developers expect these days. My point was that the command line tools are fairly easy to port and make it possible to have a platform-agnostic foundation on top of which anyone can build an IDE. Maybe not on my old Commodore PET, though (if I still had it).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
Chip Gracey said...
Yes, when you modify an instruction ahead, you must execute one in the middle ...
PhiPi said...
Thank goodness this "feature" will propagate to the P2. It's what makes coroutine implementation drop-dead simple!
dMajo said...
@PhiPi: could you explaint better? I don't get the meaning of your words. I tought that if you modify the next following line and are able to execute it immediately is better. Than if you need you can still put some line(s) between. One thing is you can do, other is you must do. What the benefit of "must" in this case?
Here's an example of two coroutines that take advantage of the pipelining:
Ping <do something>
jmpret nxt,#nxt
<do some more>
jmpret nxt,#nxt
<and still more>
jmp #Ping
Pong <do something>
jmpret nxt,#nxt
<do some more>
jmpret nxt,#nxt
<and still more>
jmp #Pong
nxt jmp #Pong
Upon the first jmpret to nxt, the address of the statement following the jmpret will be inserted into the source field of nxt, but not before the previous contents of that field have already been fetched, so the jmp will still be to Pong. The next time a jmpret to nxt takes place, a jmp to the return address within Ping takes place, and Pong's return address is inserted into the source field of nxt. This goes on ad infinitum: a little slice of Ping gets executed, then a little slice of Pong, back and forth, back and forth. And it's all made possible by pipelining.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 11/28/2009 8:39:10 PM GMT
One thing that the TRS-80's ROM BASIC provided was a system of RAM vectors that were filled in with ROM addresses upon powerup, but that could be changed to RAM addresses by the user to modify the behavior of the ROM code at key junctures. This made it possible to capture keystrokes, for example, in order to implement an onscreen editor to replace the TRS-80's line-by-numbered-line editor. Should an IDE/compiler/debugger find its way into the Prop II ROM, such a system of RAM vectors should at least be part of the picture. I still don't see sufficient value in the on-chip development proposition, however, to devote resources (especially time) that could be put to better use elsewhere. (There's still some unfinished business in the Prop I's IDE, for example.)
@Nick: We have a somewhat off topic sub-thread going on here which we should draw an end to. But...
Writing out longs in a big/little endian safe way is just a case of defining how the binary format should look and then shifting bytes out of integers, say, the right way and then writing the bytes. No #ifdefs required. You can use #ifdefs and have different code for each endianness but at least one of those will have the performance hit of rearranging the bytes, so the performance gains of using #ifdefs are moot.
Good point about Kubuntu.
@Phil, magic, I was just hunting around for the co-routine thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Try Ubuntu. With no previous experience I was able to download it (for free) and install it in a couple of hours on my laptop. Most of that time was spent reading my book since downloading the 700mb takes a little while, and the installation takes a little while. I also installed Windows 7 at the same time. That took much longer, probably because it was something like 3.5GB. So I have both installed in a dual boot setup on my laptop and they are both easy to use. Personally, I think the Ubuntu is just as good as Windows 7 from what I have seen so far.
I use the KDE version of Ubuntu (Kubuntu) on my email/gateway/firewall/backup/webcam-server machine. I generally like it. One disdvantage I see with it, though, is that the Ubuntu team doesn't maintain their apt-get repositories long enough for a given version after it's superceded by another. I don't trust the upgrade process, either, so now I'm faced with installing the latest version on a new machine and transferring all my user files and settings to it.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
> simply a geek fad that will be soon outdated and then to keep up with technology will have to get as stuffed up as Windows?
If the compiler is written in C or C++, it could be recompiled (the compiler) on almost any platform. Then you need a loader that is platform-dependant but only in the part where you open and close and write to the comm-port. The IDE needs to hook to the two programs. IDEs that run on different platforms are available, for free. ImageCraft's ICCProp almost does it that way. And a lot of other compiler do work that way. IDE and compiler are completely different things.For bells and whistles and better integration, the IDE could read information (variable size, data size, code size etc.) from a map file.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Seen it that light it looks like Windows is the "FAD" albeit not a geek one.
Nobody is suggesting creating tools that don't work on Windows. There are plenty of ways to create applications that run multiple platforms nowadays. Even if you have to do it in Java or C# (Gak and gak). Just means having to avoid using features that are unique to a single system.
Our favourite example around here is the BST tool. Runs everywhere important.
It's about time the world started to think seriously about weaning itself of off it's dependence on a single company for it's computing infrastructure. I find it a bizarre and unhealthy situation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That's exactly where the OS-dependency starts. The compiler has to be a command-line tool. So you could use it without IDE. Such a compiler could even work under (Free-)DOS, CP/M or whatever. As long as someone is willing to take the effort to compile for that platform (and make a few adjustments by platform-specific #defines).
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Oh for the love of pete, don't say that. You'll get them all excited.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
When it comes to the IDE's and GUI's making them cross platform can be a bit more tricky. However there are a number of cross platform libraries. I'm developing a graphical application now using Qt. So far everything I have wanted to do with it is working on Windows, Linux, Mac without a single change to my code. Including 3D rendering.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In theory: Yes. In praxis: No. Because you might have to switch compilers and then there's a chance you have to make adjustments (size of types etc.). But nothing impossible.
The Prop II might have enough RAM to let run a SPIN-compiler written in C. And here, you'll need your defines, because of lack of file-handling.
> Oh for the love of pete, don't say that. You'll get them all excited.
I didn't write that by chance!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
"You'll get them all excited"
You're just trying wind up us psychedelic relics with our glam rock operating systems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You'll find them within the source of Qt.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But you missed mine.
I was talking about an compiler, and not an IDE. It's no wonder that you don't need #defines when you are using an platform-independent tool. But if you write an platform-independent tool ... #defines
And if you intend to use Qt for writing a command-line compiler ... well, doesn't make much sense and won't run on DOS or CP/M or the Prop.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
The way I see it is that if you are writing a compiler it is basically just another program that reads it's input from a file or files and writes it's output to some other file. Perhaps writing and reading some intermediate files along the way, object files say.
So as long you have the standard set of open, close, read, write etc functions available and some means of getting command line arguments in then the compiler itself can be compiled on whatever platform with no #ifdefs. So there I have it a platform-independent tool with no #ifdefs.
Now if your compiler actually targets different architectures x86, ARM, PowerPC etc then that is different problem. One that can also be solved with no #ifdefs. But what we are talking about here is a Prop Spin/PASM compiler so no problem anyway.
As it happens Qt has a core library that is totally independent of the GUI stuff. So it is quite possible to write command line only programs in Qt. In fact I have used this for a server application where Qt takes care of all the cross platform networking stuff, threading, XML parsing, etc etc.
I might not want to use it for a compiler but no reason not to consider it.
Given that one can compile ADA under CP/M I think Spin/PASM would be a piece of cake [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well, the gauntlet certainly has been thrown down there!
Ok, command line interface. Very simple program - text file input and text file output. CP/M can certainly handle ADA and Pascal and other languages that are perfect for text file in and text file out.
I guess what might be unknown is what the actual program looks like. Is any of the spin/pasm compiler open source?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I cannot see the point of having an IDE and tools mask programmed in ROM as there are so many negatives to that, plus the extended time it will take to ensure there are no bugs in it, and, if there are bugs, we're stuck with them forever.
Far better I would say to develop the tools to go on SD Card, USB stick or whatever and boot the tools at start-up. Any usably decent development system is going to need the boot media for storing and transferring files on anyway.
There can be a Windows utility which loads the required files to whatever that media is, and it's easy enough to let the user decide which pins are used for what ( mouse, keyboard, TV, VGA etc ) in the process. Far better IMO than a ROM system which dictates how everything has be configured up-front.
There's also no limit to what the 'embedded IDE' can do. It can be expanded, added to and developed as time goes on. People can extend that as they wish if Parallax document how or people figure it out.
The key arguments for this path are - shorter time to market for the Prop II as it only needs the mechanism working not the embedded IDE, and the IDE can be developed in parallel or after.
I can understand the dream of an OLPC-style embedded development platform but, whether it boots from ROM or boots from external media, it's not really any different at the end of the day. If it were Flash not ROM I might feel differently, but it's not and doesn't ever seem likely to be.
On cross-platform development ...
Should be easy enough as some have said. The IDE on whatever OS can be as complicated or as simple as anyone chooses to make it; NotePad style or full-blown Visual Studio style. I don't buy into the argument that Windows gets in the way of creating a decent IDE as that depends entirely on what one wants and sets out to achieve.
My own NotePad style IDE's calling compilers ( though that rather under-sells what they actually do ) work unchanged on everything from 95 to Windows 7 and I had very few GUI or Windows API issues ( the jump from 98 to XP brought the main issues, but rather minor ). I could have added eye-candy, done cleverer things and increasingly tied myself into potential compatibility issues but didn't want to and what I have is credible and usable enough, and importantly isn't tied to anything which will likely only work on one version of Windows. If others want a better IDE then they can write one.
The only essential is that the command line compiler can handle what's thrown at it and delivers all that an IDE needs to use it. Each has to handle file paths and files slightly differently but that is a relatively minor issue. The majority of a compiler should be platform independent by nature, and not constrained or affected by OS GUI issues.
Downloading has issues because that can vary from platform to platform but a three way split solves that; IDE, compiler, downloader.
For example, a '\n' is represented differently on different platforms. If the CrLf-scheme (from Win) is to be used, you have to open files binary under *NIX and do your own reading. Other/elder compilers may have arranged functions in different header files. 16 bit compilers (for smaller OSes) have different types-sizes then compilers of bigger OSes that do have 32 bit compilers. Little-endian CPUs vs. Big-Endian CPUs will make odd results when you emmit the 32bit SPIN-codes or constants.
Platforms without an OS (like the Prop) won't allow you do do piping (pass parameters to and from the compiler).
Error-codes from the OS ("disk full", "file not found", ...) are different.
And so on and so on ...
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
Want to·experiment with the SX or just put together a cool project?
SX Spinning light display·
Want cheap wholesale electronic parts?
Transistor parts wholesale
I have worked on a C programs for embedded systems that had no problem emitting binary structures containing a mess of bits, bytes and words on big and little endian processors with no #ifdefs required. Also using different memory alignment restrictions on different processors.
16 bit vs 32 bit I admit may be an issue for raw C code.
Anyway my main point is that creating console only programs, even a compiler, that works on many platforms is not a major issue in this day and age. Been there done that.
@Hippy. I concur. I'm all for the Prop being able to support it's own development environment I just don't see the point of having it the ROM. However small it may be there must be something more generally useful to put in that space. After all the idea is to sell millions of chips, only a hand full of them are going to be used to develop on.
Did anyone actually say "Windows gets in the way of creating a decent IDE" I must have missed that. Problem is what it does is get in the way of me being able to use said decent IDE, which is a shame especially if it's author would like to have everyone use it. In that way there is no decent Windows based IDE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The Linux kernel was developed by Linus Torvalds in 1991, although full-blown Linux took another couple of years. I think I was playing with it in 1995, loaded onto my PC from 14 floppy disks.
Lots of commercial systems for "average people" are shipped with Linux, and it's used on a lot more servers than MS software, because of the higher performance and reliability.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
The fact that most people acquire a computer with something already loaded is an economy of scale. Nothing nefarious there. The fact that it is almost always one specific OS is. Microsoft has aggressive legal arrangements in place, or uses financial means to basically prevent computers from being shipped with open code, and that's why Linux is most often downloaded.
If you can't open it, and that means being able to examine all elements of it, you really don't own it, and are forced to trust others, whether or not that is a problem for you. This is a matter of computing ideology for some people, and it's important like other ideologies are important for how the vision of them, and the competition between them shapes much of the world.
Most rather ordinary people don't get overly concerned about these things, but they do benefit from the efforts of those that do. This is true in life for many things, not just computers. Your civics work this way as well, where it's not skill, but your own personal freedoms and life choices in play, not what your hardware may or may not be doing. The dynamic is the same.
A discussion like this isn't exactly productive, as in the product of it does something immediate. That makes it "thick" or "heady", or "lofty" in ways that are distracting, if taken to extremes. Be wary of that. However, it is productive in that core ideas like these, can and do govern many things, with results higher up in life potentially being troublesome, should some ideologies dominate, without consideration given to others.
An example that you can easily relate to would be your home schooling. The fact that you get to do that is the product of a discussion like this, where the product of it is law that does not overly constrain your parents. Had that discussion gone another way, or those who believe in the value of that kind of education not participated, the choice may well not be on the table for you today. Many of us believe in those kinds of choices, and have spoken where necessary to preserve them.
It is my opinion that all of us share some burden in this, where if we don't speak, we end up being spoken for, and that comes around full circle to the context in this thread, where we are simply speaking for what should be obvious reasons now. Agreement is not necessary, but mutual consideration is. It is good to know where others stand on these things. Sometimes it brings insight to participate, other times just frustration. No getting around that.
Maybe that helps some to clarify some of this thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Well. The first ever Linux kernel was given to the world in 1991.
The GNU software including the GCC compiler, that has always been a major part of a usable Linux operating system was started in 1984.
The first proper Windows OS, NT 3.1, was launched in 1993.
("Proper" as in comparable to Unix and other real operating systems).
Whilst Linux shared no code with the original Unix it obviously follows in the Unix tradition hence I said "linage back to 1969".
People do not go crazy about Linux "because it wasn't Windows". (Well perhaps some do but never mind). If you want to understand what the motivation for Linux and GNU is you should read the history here http://www.gnu.org/gnu/thegnuproject.html When Richard Stallman talks about the "software-sharing community" of the 1970's it may remind you of the Propeller community here.
"Of course the interface is not as "good looking" as Windows". Ooo now I'm steaming[noparse]:)[/noparse] I think the KDE desktop on my Debian box is much better looking than the XP I have in virtual machine here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If something like this is available on the Propeller, how does that imply being inclusive? It's not like it would be THE set of development tools, is it? Chip mentioned the life boat analogy. So then, one option would be to use Propellers to develop for Propellers. Another would be to use the kinds of tools we use now to develop for Propellers, and another will be tools not yet realized. Doesn't this marginalize the negatives, given people can and will choose how they feel they must, and with the assumption that the on chip tools are enough to boot strap subsequent efforts?
(BTW: This is a really great thread all. Some excellent discussion has taken place.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
If you write 0x01020304 on a little endian machine and send the binary representation (without rearranging) to a big endian, what will be the result?
> Of course the interface is not as "good looking" as Windows and maybe not as slick, so only computer-working people use it.
You should try a live-CD of Kubuntu or something like that. Then you could make statements like these (but won't).
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I guess it would have been more accurate to say "extract the compiler and loader from the IDE as command line tools." A good IDE should be very intimate with the compiler in order to provide features that developers expect these days. My point was that the command line tools are fairly easy to port and make it possible to have a platform-agnostic foundation on top of which anyone can build an IDE. Maybe not on my old Commodore PET, though (if I still had it).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
Ping <do something> jmpret nxt,#nxt <do some more> jmpret nxt,#nxt <and still more> jmp #Ping Pong <do something> jmpret nxt,#nxt <do some more> jmpret nxt,#nxt <and still more> jmp #Pong nxt jmp #PongUpon the first jmpret to nxt, the address of the statement following the jmpret will be inserted into the source field of nxt, but not before the previous contents of that field have already been fetched, so the jmp will still be to Pong. The next time a jmpret to nxt takes place, a jmp to the return address within Ping takes place, and Pong's return address is inserted into the source field of nxt. This goes on ad infinitum: a little slice of Ping gets executed, then a little slice of Pong, back and forth, back and forth. And it's all made possible by pipelining.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 11/28/2009 8:39:10 PM GMT
-Phil
Writing out longs in a big/little endian safe way is just a case of defining how the binary format should look and then shifting bytes out of integers, say, the right way and then writing the bytes. No #ifdefs required. You can use #ifdefs and have different code for each endianness but at least one of those will have the performance hit of rearranging the bytes, so the performance gains of using #ifdefs are moot.
Good point about Kubuntu.
@Phil, magic, I was just hunting around for the co-routine thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Try Ubuntu. With no previous experience I was able to download it (for free) and install it in a couple of hours on my laptop. Most of that time was spent reading my book since downloading the 700mb takes a little while, and the installation takes a little while. I also installed Windows 7 at the same time. That took much longer, probably because it was something like 3.5GB. So I have both installed in a dual boot setup on my laptop and they are both easy to use. Personally, I think the Ubuntu is just as good as Windows 7 from what I have seen so far.
As a side note, Ubuntu seems to be pretty popular. en.wikipedia.org/wiki/Ubuntu_(operating_system)#Reception
-Phil