Shop Learn
C/C++ on the P2 and Nano FPGA ? — Parallax Forums

C/C++ on the P2 and Nano FPGA ?

Is it now possible to compile and run C/C++ for the P2 and run it on a DE0 Nano FPGA?

I have a little idea....

More on the idea if it looks like it's even possible.
«1

Comments

  • Heater. wrote: »
    Is it now possible to compile and run C/C++ for the P2 and run it on a DE0 Nano FPGA?

    I have a little idea....

    More on the idea if it looks like it's even possible.
    Dave Hein has a compiler for a large subset of C that generates code for the P2. Unfortunately, there is not yet a version of PropGCC that supports P2.

  • What's required to get GCC to compile for the P2? It seems like it's a matter of updating GAS to assemble P2 code and changing the code generator to use the P2 mnemonics. A P2 kernel would also need to be written, but with hubexec this should be much simpler than P1's LMM kernel.

    Could the work be divided up among a small number of volunteers? I'm sure there are at least a handful of people interested in working on this. We would just need some direction on what needs to be done.
  • @Heater, so are you planning on porting Zog to the P2?
  • Dave Hein wrote: »
    What's required to get GCC to compile for the P2? It seems like it's a matter of updating GAS to assemble P2 code and changing the code generator to use the P2 mnemonics. A P2 kernel would also need to be written, but with hubexec this should be much simpler than P1's LMM kernel.

    Could the work be divided up among a small number of volunteers? I'm sure there are at least a handful of people interested in working on this. We would just need some direction on what needs to be done.
    Yes, that is what is required along with some library work. With hubexec I don't think there is even a need for a "kernel". However, low-level code like crt0 will need to be modified. My plan was to first update binutils and then look at the GCC code generator. I've been working on another project for Parallax though and haven't had time to start the P2 GCC work yet.
  • Heater.Heater. Posts: 21,233
    Dave Hein,
    ...so are you planning on porting Zog to the P2?

    No, no, this idea is much worse than that :)

    However....getting Zog working on the P2 might happen one day. It would be a bit slow for my current bad idea.

  • Heater. wrote: »
    Dave Hein,
    ...so are you planning on porting Zog to the P2?

    No, no, this idea is much worse than that :)

    However....getting Zog working on the P2 might happen one day. It would be a bit slow for my current bad idea.
    Your "bad idea" doesn't have anything to do with Javascript does it? :-)

  • Heater.Heater. Posts: 21,233
    Given that the P2 ISA is pretty much fixed now and a chip will be available "any time now" I was kind of hoping Parallax was working on getting GCC for the P2 lined up ready for launch.

  • Heater. wrote: »
    Given that the P2 ISA is pretty much fixed now and a chip will be available "any time now" I was kind of hoping Parallax was working on getting GCC for the P2 lined up ready for launch.
    It will certainly be ready for the launch of the chip itself. It may not be ready for the next FPGA image release though.

  • Heater.Heater. Posts: 21,233
    David Betz,
    Your "bad idea" doesn't have anything to do with Javascript does it? :-)
    Oh shucks, you know me to well.

    Yes it has to do with Javascript.

    However, it's not the same bad idea to do with Javascript I had before...


  • Have you tried Espruino on the ESP8266? I'm working on a wifi loader using an ESP module and I'm wondering if it would be a good idea to just embed the loader logic n Espruino rather than creating a standalone C program. My alternative would be to try Lua for the ESP.
  • Heater.Heater. Posts: 21,233
    David Betz,

    No, I don't have any ESP8266 yet. I was intrigued by the Espruino on ESP8266 idea though.

    As it happens a while ago I started work on a Propeller loader in Javascript. Basically a rewrite of your PLoadLib from prop-gcc in JS :)

    The idea was to have a Prop loader in JS that could be used with node.js or from a Chrome browser extension.

    Well, life over tool me and that came to a halt before I could even start testing it against a real Propeller.

    The code is here: https://github.com/ZiCog/propeller-loader.js

    I have no idea if this would run fast enough to program a Prop from an ESP8266 or an Espruino though.

    It would be great on the ESP8266. Just send a binary over the net and the ESP8266 programs the Prop with it.

    Perhaps I should get back to that.








  • Well, I have some C++ code to implement a wifi loader that already works on the ESP module. My idea was to just interface that C++ code with either Espruino or Lua so I have a scriptable loader on the ESP. Right now, it's just standalone. I hadn't really thought of implementing the loader directly in Javascript or Lua. I suppose that should work though. BTW, my code not only implements the Propeller ROM loader but also Jeff Martin's second-stage loader that achieves faster loading.
  • Heater.Heater. Posts: 21,233
    Ah, I see. I just wanted a loader that works in JS. Something of a challenge. Withe the advantage that if it works it's easily usable anyplace that has JS. Which seems to be everywhere now a days.

    Just now I can't think about second stage loaders. If the JS loader worked at all I would be amazed!

    I think you have inspired me to pick that up and continue with it...




  • Heater. wrote: »
    Ah, I see. I just wanted a loader that works in JS. Something of a challenge. Withe the advantage that if it works it's easily usable anyplace that has JS. Which seems to be everywhere now a days.

    Just now I can't think about second stage loaders. If the JS loader worked at all I would be amazed!

    I think you have inspired me to pick that up and continue with it...



    The problem is the tight timing required for the ROM loader protocol. That might be tricky in Javascript. Of course, it's also tricky in C++ when running under an OS that adds unpredictable delays in serial I/O.

  • Heater.Heater. Posts: 21,233
    The timing requirements are a worry.

    Perhaps JS running on raw hardware like an Espruino or ESP can do it. On the one hand it has no OS in the way and everything is event driven. On the other hand, is the interpreter fast enough?

    We shall see.

    Aside: Crazy guys around here have the idea of booting a Linux machine straight into node.js. Skip all the other layers of operating system guff.



  • Heater. wrote: »
    Aside: Crazy guys around here have the idea of booting a Linux machine straight into node.js. Skip all the other layers of operating system guff.
    Doesn't sound so crazy to me. It seems like embedded Linux systems waste a lot of time booting up a shell environment that isn't really needed for an embedded application.

  • By the way, one problem with the ESP is that it doesn't have much RAM. I'm not sure it is possible to allocate a 32K buffer for a full Propeller image. That is another reason for the two-stage loader. The first stage is small, not more than a 2K COG image. That is all that gets loaded with the ROM loader protocol. After that, the user program gets loaded using a protocol that is less timing critical.
  • That doesn't seem crazy to me at all.

    A friend and I did that in the 00's with FreeBSD. Basically whittled it down to the target application and ssh for admin. For dedicated type tasks, it's really lean, once you get the hard work done. Mostly, just sits there and does what it does. Boring, but absolutely great from a sysadmin standpoint. Lots more YouTube and mp3 time, when the stuff is boring and just works. :)

  • FYI, here is a script to download a program using the ESP module:
    FILE=$1
    SIZE=`ls -l $FILE | cut -c28-33`
    SIZE=${SIZE// /}
    echo Loading $FILE, ${SIZE} bytes
    MODULE=10.0.1.47
    curl -v -X POST $MODULE/load-begin?size=$SIZE
    curl -v -X POST -H "Expect:" --data-binary @$FILE $MODULE/load-data 
    curl -v -X POST $MODULE/load-end?command=run
    telnet $MODULE
    
    The nonsense in the first couple of lines is my hack to get the size of the file in bytes which is needed by the second-stage loader.
  • Heater.Heater. Posts: 21,233
    The thing is, if you want to run a web server on Linux traditionally you ended up with Apache or nginx and PHP and MySql etc. To support all that you needed all the Unixy infrastructure which ends up now a days needing GCC, Perl, Bash, bla bla.

    Well, how about we boot to Linux and the run node.js?

    In node we can do whatever we want in JS. None of that old baggage required.





  • Heater. wrote: »
    The thing is, if you want to run a web server on Linux traditionally you ended up with Apache or nginx and PHP and MySql etc. To support all that you needed all the Unixy infrastructure which ends up now a days needing GCC, Perl, Bash, bla bla.

    Well, how about we boot to Linux and the run node.js?

    In node we can do whatever we want in JS. None of that old baggage required.




    Doesn't node.js require some sort of database to be installed?

  • Heater.Heater. Posts: 21,233
    Node.js itself does not need any database installed. It just runs JS code.

    Of course if you are creating some web service with it you may need a database or two.

    No problem, those data bases can be on some other machine. Which is often the case in the modern world.

    For example, my little demo here: https://xn--2-umb.net/login currently only needs access to a an authentication server. The later is provided by stormpath.com but any other would do. Even one of my own.

  • Only if you are actually using a database.
  • David Betz wrote: »
    Heater. wrote: »
    The thing is, if you want to run a web server on Linux traditionally you ended up with Apache or nginx and PHP and MySql etc. To support all that you needed all the Unixy infrastructure which ends up now a days needing GCC, Perl, Bash, bla bla.

    Well, how about we boot to Linux and the run node.js?

    In node we can do whatever we want in JS. None of that old baggage required.
    Doesn't node.js require some sort of database to be installed?

    I could see npm requiring a DB engine. Perhaps that's what you were thinking of?
  • Heater.Heater. Posts: 21,233
    No, not even npm.

    npm only wants your package.json file in your project directory so it can install the required module versions for your project.

    If you choose to use a package.json file that is.
  • DavidZemon wrote: »
    David Betz wrote: »
    Heater. wrote: »
    The thing is, if you want to run a web server on Linux traditionally you ended up with Apache or nginx and PHP and MySql etc. To support all that you needed all the Unixy infrastructure which ends up now a days needing GCC, Perl, Bash, bla bla.

    Well, how about we boot to Linux and the run node.js?

    In node we can do whatever we want in JS. None of that old baggage required.
    Doesn't node.js require some sort of database to be installed?

    I could see npm requiring a DB engine. Perhaps that's what you were thinking of?
    No, I'm just thinking that many web sites require a database of some sort, usually mysql I think. Do large node.js sites use a database? Or are there no large node.js sites? :-)
  • Generally, your DB would be on a server* of its own as Heater. had mentioned. So your application/web server could boot directly to node.js and let node handle the application as well as be its own web server. It would be fun to try.

    *by server, of course in today's world, that can be anything from a physical server to a tennant running in a cloud someplace. :)
  • Heater.Heater. Posts: 21,233
    That's the thing. In the modern world a web site is not just some PC in a cupboard running a LAMP (Linux, Apache, MySql, PHP) stack.

    It's a distributed mess of machines, real and or virtual, running things like load balancers, web page servers, RESTful API servers, authentication servers, database servers, compute engines etc, etc, etc. Quite likely with different parts distributed over different data centres in different continents.

    At that point your realize LAMP is not going to cut it, especially with todays "web apps" with real-time data feeds. Node was built to exploit the event driven nature of JS to make all this much easier.

    Are there large web sites using node? Sure: ebay, Dow Johnes, LinkedIn, Uber. Here is a list https://github.com/nodejs/node-v0.x-archive/wiki/Projects,-Applications,-and-Companies-Using-Node










  • Heater. wrote: »
    That's the thing. In the modern world a web site is not just some PC in a cupboard running a LAMP (Linux, Apache, MySql, PHP) stack.

    It's a distributed mess of machines, real and or virtual, running things like load balancers, web page servers, RESTful API servers, authentication servers, database servers, compute engines etc, etc, etc. Quite likely with different parts distributed over different data centres in different continents.

    At that point your realize LAMP is not going to cut it, especially with todays "web apps" with real-time data feeds. Node was built to exploit the event driven nature of JS to make all this much easier.

    Are there large web sites using node? Sure: ebay, Dow Johnes, LinkedIn, Uber. Here is a list https://github.com/nodejs/node-v0.x-archive/wiki/Projects,-Applications,-and-Companies-Using-Node









    I realize this is the case with larger servers but why would someone install node.js on an embedded device but put their database on a cloud server? Seems like an odd configuration.

  • There is node.js support for SQLite so it could use that in the embedded device just like your smartphone does. If you need to go off-device for BIG data needs, then you may as well go to some cloud server somewhere.

    How'd we get off on this tangent anyway??

    Oh, yeah Proploader written node/espruino/javascript/etc....cool, if it can be done, opens up a lot of platforms for proploading....the more proploading going on, the more props getting loaded and that's a good thing!!
Sign In or Register to comment.