Bill Henning said...
Actually, the "MotoCog" project intends to make a 6809 virtual machine - which presumably could be made to run Flex or Nitros9. It would not be fast, but it should work. I'd estimate that the equivalent of a 1MHz 6809 may be attainable.
I am glad to see an interest in the 6809 mcu here, the Color Computer 3 in 1986 is where I began understanding computers enough to program them and eventualy learned how to design circuts with the game "Robot odyssey"/ "Droid Quest". Someone did a remake of it in Java and its floating around the www someplace. If it was not for that game, I would have never gained an interest in electronics.
Mike Green said...
There are no native C compilers for the limited memory (512 words) of the native Propeller
Under cygwinI thought I saw compiler options for commodore which used a MOS Tech. 6510, I am going to browse through some source to see if I can find it again. If I can see how it compiles for that, I/we can figure out how to do it for the Propeller, If it is even for the actual commodore. The source I am going through is the actual cygwin source tree under include/opcode there are even options for the PDP-11, lmao.... I think all of this info in the Cygwin source tree is where I can get a wealth of information on how to do this for the propeller through cygwin. I just need to understand how to add a new architecture to the Cygwin source then test it.
I was also thinking about playing around with M.E.S.S. to see what I can do with that and the propellar, but MESS does not deal with CPU's themselves, just actual consoles. Maybee the most you could do with that is make a breadboard style UI that a user could plug components into to simulate hardware, and I think that has already been done.
Its not realy emulation I am looking for, it is replication, how to create a kernel that can replicate the functions of an already made kernel, weather it is linux, Nitros9, etc... and be able to have the Propellar translate the bytecode of that kernal image into propeller machine code so it can run.
---
After all, a computer can only add, thats all it can do, period. It subtracts by adding negative numbers, it multiplies by adding multiple times, and it divides by adding negative numbers multiple times. it is just a switch that needs to be manipulated to achieve what we want.
You have to have enough memory to fit the program in.
Adding a new architecture to an existing compiler toolchain and (particularly important) producing efficient code is difficult at best. The Prop is what's called a RISC architecture, very unlike the 65xx series processors, very unlike the 6809, and very unlike the Z80, just for a few examples. The ARM architecture is also RISC as are some other modern processors.
You've clearly got a lot to learn about computers, compilers, operating systems, and other related topics. I strongly suggest you start with some kind of introductory text on each subject. Make use of the Wikipedia for explanations. Jack Crenshaw has an excellent introduction to compiler building here: compilers.iecc.com/crenshaw/. Don't just read the references. Work through examples. Write and debug a small compiler. Write and debug a small operating system. There are all kinds of excellent emulators available for use with a PC. Find something that had a "front panel" where you could enter instructions and data by hand using switches. I know for sure there's one for the PDP-8 and that had a simple instruction set as well. There were some relatively sophisticated compilers and operating systems available for the PDP-8 including a time-sharing system. If the PDP-8 doesn't appeal to you, I'm sure you could find all sorts of emulators for processors of that generation to work with.
Post Edited (Mike Green) : 7/9/2010 6:37:46 PM GMT
Have you looked at the spinix thread?· I'm basically trying to replicate the environment of linux, but on a much smaller scale.· Would you be interested in joining forces on this?· There are several linux apps that need to be written or ported, such as grep, vi, man, and so on.· I am writing it in Spin, but in a few cases I started with C code, such as for tar and ed.· I have a utility called CSPIN that I use to convert it Spin.
Mike Green said...
You've clearly got a lot to learn about computers, compilers, operating systems, and other related topics. I strongly suggest you start with some kind of introductory text on each subject.
I know about the memory constraints, and I know about computers too, telling me that I need to learn about them is insulting. I don't feel it is proper to publicly insult me in that manner, you can just ignore my post or if you feel you need to insult me, do it in a PM or keep it to yourself.
My comment was not intended as an insult in any way. What I said was what I felt reading your messages. I hate to see someone with enthusiasm either making a bad product because they don't know what they're doing or losing interest because the task ends up way beyond their experience / knowledge level. There were some great books in the 1970's and 1980's on basic principles of compiler design and operating system design some of them written by those who developed the ideas originally. I don't know what's available these days for college-level texts, but, like in a lot of subjects, earlier texts are sometimes easier to really understand than more current texts.
Jorge P: OK that sounds better, dropping our sights down from full up Linux to something more Prop sized along the lines of OS 9, FLEX etc.
I'm not sure I understand what cygwyn has got to do with all this. If you want a cross compiler for the Prop there are many already:
0) BDST is a Prop Tool clone that runs on Linux/Mac/Windows and compiles Spin/PASM and BASIC for the Prop.
1) Homespun is a Spin/PASM compiler written on Java. Runs wherever Java does.
2) ICC runs on Winows and compiles to Prop LMM target.
3) Catalina runs on Windows or Linux and compiles to Prop LMM target (different LMM than ICC)
4) The GCC C/C++ compiler for the 32 bit ZPU processor can be run under Linux and Windows (under cygwin). The resulting executables can be run on the Prop under the Zog virtual machine.
5) The GCC compiler for 6809 run under Linux and Windows (cygwin). The resulting executables can be run under the MoCog 6809 emulator, when/if I ever finish it. Hence talk of FLEX here.
6) yZ80 and ZiCog will run Z80 code on the Prop. That can be compiled from C with BDS C on Windows or Linux.
What's the best for a Prop OS? No idea.
If you want to compile for the Prop on the Prop itself there is Sphinx for Spin, some versions of BASIC, the BDS C compile for Z80 emulations and a C compiler from Cubix for the 6809. The later of which are not much use a Prop OS I think.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think the spinux thread is exactly what I was trying to do, with the exception of a standardized system bus. I do need to understand more about compiler theory, and I will read about it. I have referanced the link you posted, in the past, but it was only for referance, I thank you for the reminder of its existance since I did lose it within my bookmarks. However I was distracted and forgot about Crenshaws documents when I was interested in learning how to create an x86 based OS after being overwhelmed with OS-Kit a few years ago, It takes a few brains to discuss and theorize about a system design since it realy is a large task to undertake alone.
I spend most of my spare time reading documentation and data sheets from the IT industry since that is what I have been interested in since I was very young, I have even learned how to make a computer using switches and relays, which isn't verry dificult, just expensive. The process is in the Book called "CODE" by the Microsoft Press, and it is very descriptive in laymens terms of how computers work. It gave me a better insight into assembly language wich is rare to see a modern book (2000) published on the subject without being specificaly for a certain architecture, especialy from Microsoft. I would reccomend that book to anyone new to programming in any language. It even goes to the extent of showing you how to develop instructions like MOV, ADD, etc.. as well as how to store data in specific areas of memory, all using switches and relays(or even transisters).
I was realy offended by a comment in a previouse post prior to reading yours, and I believe it carried on to yours where I in turn posted my reply directly to you, when I shouldn't have. I hope not to make enimies here or elsewhere for that matter.
heater said...
I'm not sure I understand what cygwyn has got to do with all this.
I was only vaguely aware of some of the cross compilers, when I saw in the cygwin source code the variouse micros that you could cross complie to/from, I saw alot of old old micros supported so I figured why not the propeller. In creating one, I intend to learn from it the variouse opcodes and how to translate them within other systems/micros. Seeing and investigating the other micros and learning of the variouse OS's they ran, and their history, I figured making a port using cygwin would be an extreamly educational task, but it looks like I will go that route on my own. I already understand linux, and enjoy playing with the propellar, as well as cygwin, So I thought why not join all 3 to gain a greater understanding of each of them. All while making yet another usefull tool to someone somewhere. I think it would be rewarding for myself, so I thought I'd introduce some ideas to the community.
Even though you, or others have already done these things, You, and they, got a greater understanding from it, That is exactly what I am trying to achieve for myself, but I figured others might enjoy the task as well, and there are others who are enjoying it. Just apparently not in this thread.
That being said, I would like an admin to lock this thread from further posts and let all its negativity slowly drop down the thread tree. I will no longer post about the subject since most posts have taken away the learning experince or made it less fun than it was intended, although I know thats not what you all intended to do, the reality is thats what is happening.
You should not worry about the negativity and for sure don't take it personally.
We opened here with a wildly optimistic idea of Linux on the Prop, an idea that has come up from time to time. We had an interesting think and debate about what it would take to achieve that goal and whether the effort would be worth it.
The consensus is "no". Well OK so be it, we had an interesting path to travel to get to that result. And it has stimulated ideas about what we really want and how it may be done. In fact that "no" is quite a positive result.
So sure, start a new thread with the next ideas, no need to lock this one. I have a few dead end threads hanging around here as well. Not all thought experiments have to go anywhere there are many blind allies. It's just that here we are thinking in public.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The amount of work to port linux to the prop is imo more work than just writing an os from scratch for the prop. Furthermore an OS built for the prop would be much much faster and feasible from a usefulness standpoint.
[noparse][[/noparse]quote]
After all, a computer can only add, thats all it can do, period. It subtracts by adding negative numbers, it multiplies by adding multiple times, and it divides by adding negative numbers multiple times. it is just a switch that needs to be manipulated to achieve what we want.
Ehhh, not really. Subtraction vs addition is just how you look at it. Since we designed the arrangement of bits that represent numbers and negative numbers, and defined the operations on those bits... what computers can 'only do' is simply what we made them do. Why would be design different instructions in the alu when the current ones could be used for those with little change? Now... multiplication on the other hand. This can be done through repeated addition, but sophisticated multiplication circuits are actually quite parallel. The circuit is not just a loop and add. One of the best methods for division or multiplication is very simple... a lookup table that stores the results of each combination of multiplied numbers using the two numbers as the address into the table. That's pretty much how we do when we memorize multiplication tables.
What about analog computers? Their operations are most certainly not done this way at all.
I guess what I'm really trying to say is that computers can only do what they do... because it's all we can do. They are limited in complexity by our own understanding. They can be built to do anything physically and computationally possible... so long as we can understand those things enough to do it.
Why do computers behave like they do? Why did we go to digital? There are many other directions that could have been taken with them. What is possible is a small factor compared to what is useful, economical, etc... The same considerations should be taken into account when thinking about said linux port.
Ohh, and do note that I (and many many people here) use linux on a daily basis, have read the dragon book, renshaws paper, etc, designed a couple programming languages, written compilers for them (parser and all from scratch, no bison and yacc about it), even designed my own processor in an fpga with an assembly language of my own design. (Actually drew the circuits then made verilog code based on them.)
Btw, does anyone know of a good embedded linux capable pc under $100 or so? I know they're out there... hiding from me. I've always wanted lua on a robotic platform. Hell, someone should figure out a way to get lua to fit on the prop. [noparse]:D[/noparse]
Gumstix makes a line of PXA255-based embedded Linux mini-boards. The cheapest processor is $130 and includes a micro-SD card socket. You can add Ethernet for under $100 and they have a variety of other I/O mini-boards. I've not seen any cheaper embedded Linux systems although they must be out there.
James Newman: "I've always wanted lua on a robotic platform."
Strangely enough you can already run lua on the Propeller. RossH includes it in the Catalina C compiler package. I like lua to so I'll probably try and get his lua version running under Zog at some point.
As for a 100 dollar Linux board, the ones I'm looking at are not quite down to that price but close enough for me:
I have replaced the Zipit's original Linux with Debian Lenny, everything works including the WIFI. I hope to soon have the Zipit talking to my Propellers over a serial connection that can be easily added.
When my IGEP and Beagle arrive I will be pestering BradC for a cross compile of BST for ARM so that we can develop for the Prop on them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
James Newman said...
Btw, does anyone know of a good embedded linux capable pc under $100 or so? I know they're out there... hiding from me. I've always wanted lua on a robotic platform. Hell, someone should figure out a way to get lua to fit on the prop. [noparse]:D[/noparse]
What I see in Catalina seems to be a standalone Lua interpreter, but not integrated with the PropHW ...
Actually I was looking into the MIZAR32 board to run eLua in it, when I discovered the Propeller - which they use in MIZAR32 as the VGA-driver.
I would love to have an eLua as OS for Prop. because I need scripting capabilities - and I am very enthusiastic about propellers capabilities - and even more about the prospects for Prop2
So - are there any activities somewhere around Lua / eLua and Prop ??
thanks MJB
- btw - are there any PropHeads in Germany - where I live ?
I don't see it as un realistic I see it as a difficult project that will require support from the entire propellar community......
While I can understand your point of view, this is unlikely to happen - a bit like herding cats. Best to study OSes on devices intended for them and to study micro-control on devices that are appropriate for them.
The Raspberry Pi and the BeagleBoard seem to be what you require.
I see it as unrealistic. Even on a Prop II Linux would be horribly slow. No fast access to memory, no mmu etc etc. It has no practical use given the huge range of chips available that are better suited to running Linux and very cheap. The entire Propeller community probably has better things to do.
That's not to say some lone geek may not take it on as an intellectual challenge and surprise us all.
I'm pretty sure you could port uCLinux (a linux distro without MMU) to the propeller, I don't think it uses a lot of memory, but it still uses more than the propeller has.
But you could use one of Bill Henning's Morpheus and Mem+ boards, I think they give you a total of 16MB with four Mem+ boards.
I'm pretty sure you could port uCLinux (a linux distro without MMU) to the propeller, I don't think it uses a lot of memory, but it still uses more than the propeller has.
But you could use one of Bill Henning's Morpheus and Mem+ microcontrollers, I think that gives you a total of 16MB with four Mem+ boards.
Thanks,
Devin
Hi Devin.
Even 16MB is most likely not big enough. Just the kernel is 4MB on i686.
There are a few issues aside from the memory space problems though.
1) The Linux kernel relies on an interrupt mechanism for scheduling.
2) The GCC newlib library is necessary and was never fully ported because it was too big to bother with.
The cost of dealing with these (and propably other issues) is uncertain.
I'm not saying it can't be done because I know better - some people do things just to prove they are possible.
It's just that the end result of all the effort required to make it happen is a questionable return.
Why not use a cheapie WR703N for ~$22 that has been hacked with *nix and has WiFi. There is an accessible ttl 3V serial port inside. Add a prop for what else you require. It's not fast, but is cheap and simple.
16MB and no MMU should be quite OK for Linux. A quick search of YouTube reveals a demo of various Linux versions running on such a machine, a bread boarded 68000 computer.
Funnily he uses a 555 timer chip to get the Linux timer tick. We would probably need a little hack to the propgcc LLM loop to respond to the timer.
Libraries should not be a problem if we use busybox.
Sounds like we are good to go with Linux on the Prop now.
Has anyone pointed propgcc at a Linux kernel tree yet?
The Propeller is Turing complete so it's obviously possible to run Linux. Just not very efficiently. Let the Propeller emulate another computer where Linux runs already, and you're done. But it may take a while to boot up... Dmitry Grinberg's 32-bit ARM emulation running on an 8-bit AVR took six hours to start Ubuntu (without X11). Or 2 hours to an initial single-user bash prompt (init=/bin/bash).
The topic of Linux on the Propeller first came up many years ago. All sorts of solutions have been proposed including writing a emulator for some CPU and peripherals for which there is a ready made Linux build. Like that ARM emulation on AVR for example.
We were getting closer with the Zog ZPU virtual machine on the Prop for which there is a port of GCC.
But now we have a GCC port for the Propeller. propgcc. We no longer need the ultra slow emulation stage. We can compile Linux for the Propeller.
The big slow down will be the need to use external RAM. But if that AVR can do it so can the Prop.
What do wee need?
0) A GCC compiler for the Propeller - Check.
1) A boot loader - I'm think the propgcc loader will already do this - Check.
2) RAM - The Prop II will be supplied on a module with 32MB SDRAM - Check.
3) UART interface - Just hack a Linux driver to use an existing one - Check.
4) Block storage device - We have SD drivers galore. - Check.
5) Timer tick - needs a "check for interrupt" hacking into the LMM kernel, can't be so hard. - Check
All in all it starts to sound as doable as getting CP/M to run on the Propeller, only bigger. And we have already done that.
The topic of Linux on the Propeller first came up many years ago. All sorts of solutions have been proposed including writing a emulator for some CPU and peripherals for which there is a ready made Linux build. Like that ARM emulation on AVR for example.
We were getting closer with the Zog ZPU virtual machine on the Prop for which there is a port of GCC.
But now we have a GCC port for the Propeller. propgcc. We no longer need the ultra slow emulation stage. We can compile Linux for the Propeller.
The big slow down will be the need to use external RAM. But if that AVR can do it so can the Prop.
What do wee need?
0) A GCC compiler for the Propeller - Check.
1) A boot loader - I'm think the propgcc loader will already do this - Check.
2) RAM - The Prop II will be supplied on a module with 32MB SDRAM - Check.
3) UART interface - Just hack a Linux driver to use an existing one - Check.
4) Block storage device - We have SD drivers galore. - Check.
5) Timer tick - needs a "check for interrupt" hacking into the LMM kernel, can't be so hard. - Check
All in all it starts to sound as doable as getting CP/M to run on the Propeller, only bigger. And we have already done that.
Comments
I am glad to see an interest in the 6809 mcu here, the Color Computer 3 in 1986 is where I began understanding computers enough to program them and eventualy learned how to design circuts with the game "Robot odyssey"/ "Droid Quest". Someone did a remake of it in Java and its floating around the www someplace. If it was not for that game, I would have never gained an interest in electronics.
Under cygwinI thought I saw compiler options for commodore which used a MOS Tech. 6510, I am going to browse through some source to see if I can find it again. If I can see how it compiles for that, I/we can figure out how to do it for the Propeller, If it is even for the actual commodore. The source I am going through is the actual cygwin source tree under include/opcode there are even options for the PDP-11, lmao.... I think all of this info in the Cygwin source tree is where I can get a wealth of information on how to do this for the propeller through cygwin. I just need to understand how to add a new architecture to the Cygwin source then test it.
I was also thinking about playing around with M.E.S.S. to see what I can do with that and the propellar, but MESS does not deal with CPU's themselves, just actual consoles. Maybee the most you could do with that is make a breadboard style UI that a user could plug components into to simulate hardware, and I think that has already been done.
Its not realy emulation I am looking for, it is replication, how to create a kernel that can replicate the functions of an already made kernel, weather it is linux, Nitros9, etc... and be able to have the Propellar translate the bytecode of that kernal image into propeller machine code so it can run.
---
After all, a computer can only add, thats all it can do, period. It subtracts by adding negative numbers, it multiplies by adding multiple times, and it divides by adding negative numbers multiple times. it is just a switch that needs to be manipulated to achieve what we want.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
Adding a new architecture to an existing compiler toolchain and (particularly important) producing efficient code is difficult at best. The Prop is what's called a RISC architecture, very unlike the 65xx series processors, very unlike the 6809, and very unlike the Z80, just for a few examples. The ARM architecture is also RISC as are some other modern processors.
You've clearly got a lot to learn about computers, compilers, operating systems, and other related topics. I strongly suggest you start with some kind of introductory text on each subject. Make use of the Wikipedia for explanations. Jack Crenshaw has an excellent introduction to compiler building here: compilers.iecc.com/crenshaw/. Don't just read the references. Work through examples. Write and debug a small compiler. Write and debug a small operating system. There are all kinds of excellent emulators available for use with a PC. Find something that had a "front panel" where you could enter instructions and data by hand using switches. I know for sure there's one for the PDP-8 and that had a simple instruction set as well. There were some relatively sophisticated compilers and operating systems available for the PDP-8 including a time-sharing system. If the PDP-8 doesn't appeal to you, I'm sure you could find all sorts of emulators for processors of that generation to work with.
Post Edited (Mike Green) : 7/9/2010 6:37:46 PM GMT
Have you looked at the spinix thread?· I'm basically trying to replicate the environment of linux, but on a much smaller scale.· Would you be interested in joining forces on this?· There are several linux apps that need to be written or ported, such as grep, vi, man, and so on.· I am writing it in Spin, but in a few cases I started with C code, such as for tar and ed.· I have a utility called CSPIN that I use to convert it Spin.
Dave
I know about the memory constraints, and I know about computers too, telling me that I need to learn about them is insulting. I don't feel it is proper to publicly insult me in that manner, you can just ignore my post or if you feel you need to insult me, do it in a PM or keep it to yourself.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
I'm not sure I understand what cygwyn has got to do with all this. If you want a cross compiler for the Prop there are many already:
0) BDST is a Prop Tool clone that runs on Linux/Mac/Windows and compiles Spin/PASM and BASIC for the Prop.
1) Homespun is a Spin/PASM compiler written on Java. Runs wherever Java does.
2) ICC runs on Winows and compiles to Prop LMM target.
3) Catalina runs on Windows or Linux and compiles to Prop LMM target (different LMM than ICC)
4) The GCC C/C++ compiler for the 32 bit ZPU processor can be run under Linux and Windows (under cygwin). The resulting executables can be run on the Prop under the Zog virtual machine.
5) The GCC compiler for 6809 run under Linux and Windows (cygwin). The resulting executables can be run under the MoCog 6809 emulator, when/if I ever finish it. Hence talk of FLEX here.
6) yZ80 and ZiCog will run Z80 code on the Prop. That can be compiled from C with BDS C on Windows or Linux.
What's the best for a Prop OS? No idea.
If you want to compile for the Prop on the Prop itself there is Sphinx for Spin, some versions of BASIC, the BDS C compile for Z80 emulations and a C compiler from Cubix for the 6809. The later of which are not much use a Prop OS I think.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/9/2010 7:41:13 PM GMT
I spend most of my spare time reading documentation and data sheets from the IT industry since that is what I have been interested in since I was very young, I have even learned how to make a computer using switches and relays, which isn't verry dificult, just expensive. The process is in the Book called "CODE" by the Microsoft Press, and it is very descriptive in laymens terms of how computers work. It gave me a better insight into assembly language wich is rare to see a modern book (2000) published on the subject without being specificaly for a certain architecture, especialy from Microsoft. I would reccomend that book to anyone new to programming in any language. It even goes to the extent of showing you how to develop instructions like MOV, ADD, etc.. as well as how to store data in specific areas of memory, all using switches and relays(or even transisters).
I was realy offended by a comment in a previouse post prior to reading yours, and I believe it carried on to yours where I in turn posted my reply directly to you, when I shouldn't have. I hope not to make enimies here or elsewhere for that matter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
I was only vaguely aware of some of the cross compilers, when I saw in the cygwin source code the variouse micros that you could cross complie to/from, I saw alot of old old micros supported so I figured why not the propeller. In creating one, I intend to learn from it the variouse opcodes and how to translate them within other systems/micros. Seeing and investigating the other micros and learning of the variouse OS's they ran, and their history, I figured making a port using cygwin would be an extreamly educational task, but it looks like I will go that route on my own. I already understand linux, and enjoy playing with the propellar, as well as cygwin, So I thought why not join all 3 to gain a greater understanding of each of them. All while making yet another usefull tool to someone somewhere. I think it would be rewarding for myself, so I thought I'd introduce some ideas to the community.
Even though you, or others have already done these things, You, and they, got a greater understanding from it, That is exactly what I am trying to achieve for myself, but I figured others might enjoy the task as well, and there are others who are enjoying it. Just apparently not in this thread.
That being said, I would like an admin to lock this thread from further posts and let all its negativity slowly drop down the thread tree. I will no longer post about the subject since most posts have taken away the learning experince or made it less fun than it was intended, although I know thats not what you all intended to do, the reality is thats what is happening.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
We opened here with a wildly optimistic idea of Linux on the Prop, an idea that has come up from time to time. We had an interesting think and debate about what it would take to achieve that goal and whether the effort would be worth it.
The consensus is "no". Well OK so be it, we had an interesting path to travel to get to that result. And it has stimulated ideas about what we really want and how it may be done. In fact that "no" is quite a positive result.
So sure, start a new thread with the next ideas, no need to lock this one. I have a few dead end threads hanging around here as well. Not all thought experiments have to go anywhere there are many blind allies. It's just that here we are thinking in public.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
[noparse][[/noparse]quote]
After all, a computer can only add, thats all it can do, period. It subtracts by adding negative numbers, it multiplies by adding multiple times, and it divides by adding negative numbers multiple times. it is just a switch that needs to be manipulated to achieve what we want.
Ehhh, not really. Subtraction vs addition is just how you look at it. Since we designed the arrangement of bits that represent numbers and negative numbers, and defined the operations on those bits... what computers can 'only do' is simply what we made them do. Why would be design different instructions in the alu when the current ones could be used for those with little change? Now... multiplication on the other hand. This can be done through repeated addition, but sophisticated multiplication circuits are actually quite parallel. The circuit is not just a loop and add. One of the best methods for division or multiplication is very simple... a lookup table that stores the results of each combination of multiplied numbers using the two numbers as the address into the table. That's pretty much how we do when we memorize multiplication tables.
What about analog computers? Their operations are most certainly not done this way at all.
I guess what I'm really trying to say is that computers can only do what they do... because it's all we can do. They are limited in complexity by our own understanding. They can be built to do anything physically and computationally possible... so long as we can understand those things enough to do it.
Why do computers behave like they do? Why did we go to digital? There are many other directions that could have been taken with them. What is possible is a small factor compared to what is useful, economical, etc... The same considerations should be taken into account when thinking about said linux port.
Ohh, and do note that I (and many many people here) use linux on a daily basis, have read the dragon book, renshaws paper, etc, designed a couple programming languages, written compilers for them (parser and all from scratch, no bison and yacc about it), even designed my own processor in an fpga with an assembly language of my own design. (Actually drew the circuits then made verilog code based on them.)
Btw, does anyone know of a good embedded linux capable pc under $100 or so? I know they're out there... hiding from me. I've always wanted lua on a robotic platform. Hell, someone should figure out a way to get lua to fit on the prop. [noparse]:D[/noparse]
Strangely enough you can already run lua on the Propeller. RossH includes it in the Catalina C compiler package. I like lua to so I'll probably try and get his lua version running under Zog at some point.
As for a 100 dollar Linux board, the ones I'm looking at are not quite down to that price but close enough for me:
The IGEP verison 2 is only 145 euro and is basically a full up ARM based PC the size of a credit card. Only 130 euro for the version without WIFI. www.igep.es/index.php?option=com_content&view=article&id=46&Itemid=55
The Beagle board is also a fully loaded ARM Linux machine for 149 dollars. beagleboard.org/
Recently I've been playing with Debian on a Zipit Wireless Messenger 2 which can be had for 45 dollars here www.zipitwireless.com/default.aspx?skinid=1
I have replaced the Zipit's original Linux with Debian Lenny, everything works including the WIFI. I hope to soon have the Zipit talking to my Propellers over a serial connection that can be easily added.
When my IGEP and Beagle arrive I will be pestering BradC for a cross compile of BST for ARM so that we can develop for the Prop on them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Check these mini-itx boards out:
http://ncix.com/products/?sku=50437&vpn=BOXD510MO&manufacture=Intel
http://ncix.com/products/?sku=50437&vpn=BOXD510MO&manufacture=Intel
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
IGEP is more than $100... but wow. That is one nice piece of hardware.
I'll have to look into the lua via catalina. Thanks for the info.
I like the mini and pico pc boards out there. For the uses I'm picturing however, the cost of additional disk drive/memory/etc seems to be much.
Lua - did you made any progress wit Lua on Prop?
What I see in Catalina seems to be a standalone Lua interpreter, but not integrated with the PropHW ...
Actually I was looking into the MIZAR32 board to run eLua in it, when I discovered the Propeller - which they use in MIZAR32 as the VGA-driver.
I would love to have an eLua as OS for Prop. because I need scripting capabilities - and I am very enthusiastic about propellers capabilities - and even more about the prospects for Prop2
So - are there any activities somewhere around Lua / eLua and Prop ??
thanks MJB
- btw - are there any PropHeads in Germany - where I live ?
http://www.eluaproject.net/ the embedded Lua project home page
here: http://hempeldesigngroup.com/lego/pbLua/ - no prop :-( but LEGO Robots with Lua
While I can understand your point of view, this is unlikely to happen - a bit like herding cats. Best to study OSes on devices intended for them and to study micro-control on devices that are appropriate for them.
The Raspberry Pi and the BeagleBoard seem to be what you require.
That's not to say some lone geek may not take it on as an intellectual challenge and surprise us all.
I'm pretty sure you could port uCLinux (a linux distro without MMU) to the propeller, I don't think it uses a lot of memory, but it still uses more than the propeller has.
But you could use one of Bill Henning's Morpheus and Mem+ boards, I think they give you a total of 16MB with four Mem+ boards.
Thanks,
Devin
Hi Devin.
Even 16MB is most likely not big enough. Just the kernel is 4MB on i686.
There are a few issues aside from the memory space problems though.
1) The Linux kernel relies on an interrupt mechanism for scheduling.
2) The GCC newlib library is necessary and was never fully ported because it was too big to bother with.
The cost of dealing with these (and propably other issues) is uncertain.
I'm not saying it can't be done because I know better - some people do things just to prove they are possible.
It's just that the end result of all the effort required to make it happen is a questionable return.
Best Regards,
--Steve
Funnily he uses a 555 timer chip to get the Linux timer tick. We would probably need a little hack to the propgcc LLM loop to respond to the timer.
Libraries should not be a problem if we use busybox.
Sounds like we are good to go with Linux on the Prop now.
Has anyone pointed propgcc at a Linux kernel tree yet?
-Tor
The topic of Linux on the Propeller first came up many years ago. All sorts of solutions have been proposed including writing a emulator for some CPU and peripherals for which there is a ready made Linux build. Like that ARM emulation on AVR for example.
We were getting closer with the Zog ZPU virtual machine on the Prop for which there is a port of GCC.
But now we have a GCC port for the Propeller. propgcc. We no longer need the ultra slow emulation stage. We can compile Linux for the Propeller.
The big slow down will be the need to use external RAM. But if that AVR can do it so can the Prop.
What do wee need?
0) A GCC compiler for the Propeller - Check.
1) A boot loader - I'm think the propgcc loader will already do this - Check.
2) RAM - The Prop II will be supplied on a module with 32MB SDRAM - Check.
3) UART interface - Just hack a Linux driver to use an existing one - Check.
4) Block storage device - We have SD drivers galore. - Check.
5) Timer tick - needs a "check for interrupt" hacking into the LMM kernel, can't be so hard. - Check
All in all it starts to sound as doable as getting CP/M to run on the Propeller, only bigger. And we have already done that.
What am I missing here?
http://www.youtube.com/watch?v=GJmPS3jMwD4
That amazing breadboard arrangement evolved into this:
http://www.youtube.com/watch?v=gu0Y4vliJcQ
http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit
The four hour boot time is a low performance bar to beat.
Still the kernel itself does not depend on any libraries so we should be able to get that started up. Then worry about what happens next.
It would actually be possible on as little as a DE0-Nano running a single P2 cog... just use blocking serial and SD drivers.
Much easier on a DE2-115, or a P2 module