Go language support?

bgpbgp Posts: 33
edited 2016-06-11 - 19:52:19 in Microcontrollers
Hello,

Just wondering if anyone had info on the effort required to make the Go programming language work on a Propeller chip. I'm sure the first challenge would be the considerable memory required - a rather complete runtime is embedded in the output executable for even somewhat trivial applications compiled from Go - a "hello world" program compiled on my Mac laptop outputs a 2.2mb executable, and it's common for more complex programs that use other parts of the std lib to be more like 8-12mb on disk. But assuming one were using XMM (or other appropriate memory model - I don't claim to have a comprehensive understanding of propeller architecture, I'm only casually acquainted with writing Spin and C on a propeller) and potentially an add-on chip with additional memory (flash or otherwise), and some restrictions on which parts of the std lib are supported - it seems like it would be possible.

In contrast with languages like Python and Java, Go outputs native executables. There's no byte code, and the runtime is included into the output, which I think helps matters in terms of overall simplicity (although it makes for a bigger output).

All that said, I was just curious if anyone has any sort of assessment of what effort would be required to do a port like this? I very much like the propeller multicore architecture, and while I see the point of Spin, and am aware of Propeller ASM, and I've used the C compiler, it just isn't the same as being able to work in a higher level language. Maybe it's just too heavy for this environment, but I'm interested to see what other people think about this.

-bgp

Comments

  • There's also a well developed Forth interpreter (actually two completely different ones). Tachyon Forth is my favorite.

    Porting a high level language is a big effort and the performance of the result is going to be terrible. The primary issue is memory. The actual processors (cogs) in the Propeller have 496 32-bit words of memory each (which is the instruction size). These 8 processors share 32K bytes of (hub) memory which is normally used for the Spin interpretive code and data. If your C program is very small, it might fit in a cog. More commonly small pieces of code are loaded into a cog as needed while most of the code is left in hub memory and executed interpretively. Once your program becomes too large for hub memory, it has to be stored in some kind of external flash memory or serial RAM or an SD card and effectively paged into a cache in hub memory. The paging and interpretation add a significant amount of overhead.
  • jmgjmg Posts: 13,607
    bgp wrote: »
    I very much like the propeller multicore architecture, and while I see the point of Spin, and am aware of Propeller ASM, and I've used the C compiler, it just isn't the same as being able to work in a higher level language.
    There is a gccgo, so you could try using that ?
    The other question, is Why ?
    ie What attributes, that are significant to embedded control, does Go bring ?
    It is somewhat cleaner than C, but many of the automated features are not suited to lightweight Microcontrollers.

    PropBASIC is also somewhat cleaner than C, and it does match the Prop1 / (Prop 2?) well.
  • bgpbgp Posts: 33
    edited 2016-06-12 - 01:18:12
    Thanks for the replies.

    Will look more at Forth - I'm not familiar with it.

    Mike, gotcha on the architecture and how the cogs work. Sounds like having an effective paging or interpreter strategy would be key to decent performance.

    The main things I think Go would bring to the table would be easier implementation of more sophisticated algorithms. For example, Goroutines would seem, at first glance, a good match for the concept of using cogs as threads. (Goroutines are "multiplexed onto native threads", meaning the Go runtime has it's own scheduler and allows you to have way more concurrent goroutines that you have actual threads on your system - a concept that works well on your average Intel desktop CPU - but no idea of it's actual usefulness here). IMO it also tends to be easier to get algorithms correct in Go than in C because of the protections of the language - disallowing pointer arithmetic, the compiler figures out stack vs heap allocation (avoiding many of the bullets one tends to aim at his own feet while dealing with C and especially C++).

    I realize at the same time that some features - like garbage collection - may just be too much and not really be compatible in any feasible way with the amount of CPU available in an environment like this.

    If I can look into it more and get some idea myself of any possibly viable approach, I'll be sure to post what I find. And if anyone has any links to something that solves this for another language or any descriptions of approaches, etc. that might be useful, feel free to post them.
  • Do look at the Tachyon Forth thread here. It's a very efficient implementation of (non-standard) Forth for the Propeller. It provides for multiple threads per cog and uses short native code sequences to implement high speed mostly I/O operations. Even if you don't care for Forth, the design choices made are instructive. Since pretty much any high level language implementation for the Propeller is going to have to be interpreted or mostly interpreted, Tachyon Forth is a good toolbox of ideas.
  • ElectrodudeElectrodude Posts: 1,280
    edited 2016-06-12 - 02:56:25
    Go has for a long time been high on my list of languages that I like but never got around to actually writing anything in. Its main appeal to me was that it was fairly low-level, much like C, but that it dealt with memory management and thread synchronization for you. But I don't think it would be a good fit for the Propeller. Most Propeller applications do almost no memory management, and cog synchronization is fairly easy on the Propeller, which has no out-of-order execution or caches to complicate things.

    Typical Propeller applications dedicate one or maybe a few tasks to each cog. I've never heard of any Propeller application where tasks move between cogs. On the other hand, goroutines generally move between cores, so that if one is running for a while, others can still run.

    For example, for a Propeller data acquisition and relay system I made, one cog provided several software UARTS, two collected data through the UART cog and some other interfaces, and one sent all of the collected data over an XBee digital radio to a laptop where the data was logged. One of the collector cogs talked to roughly half of the attached peripherals, and the other handled the rest. Another cog ran a sensor driver that one of the data collector cogs read data from. In addition, the sender cog accepted remote commands to change various parameters and would occasionally update an LCD with some numbers calculated from the latest sensor readings. Every cog had a few tasks that only it ever did. No tasks ever moved between cogs. If tasks were allowed to move, I'd have to worry about timing, starvation, and other sorts of fun. There was no heap, although fixed-size sample structures were allocated out of a large buffer that took up all otherwise unused RAM, and this buffer was only ever accessed by the sender cog, which was also in charge of storing samples when it was time.
  • Have you seen this ?

    Gobot is a framework for robotics, physical computing, and the Internet of Things (IoT), written in the Go programming language

    https://gobot.io/

  • Gobot looks like fun!

    For Arduino, they list this:
    This package provides the adaptor for microcontrollers such as Arduino that support the Firmata protocol

    They aren't actually running GO on the Arduino.

    We really need a subset* of Firmata to run on the Propeller, that woudl open more doors of people wanting to interface PC and such to Propellers through Processing and other host based languages that talk to Firmata capable devices.

    *I said subset because the Arduino implementation makes use of the built-in analog capabilities on the Arduino - we don't have any standard, native analog unless you use the Activity Board as a minimum standard.
    MOV OUTA, PEACE <div>Rick </div><div>"I've stopped using programming languages with Garbage Collection, they keep deleting my source code!!"</div>
  • Funny you say that.

    ekpyroticfrood.net/?cat=2

    This uses a Firmata like code base running on a Prop that talks to a PC running ROS.

    I used this to build my robot from, Chris has done a great job and has a forum with great support.

    Might be worth a look as a start.
  • bgpbgp Posts: 33
    edited 2016-06-14 - 00:24:31
    Gobot is actually how I got interested in asking about this.
    mindrobots wrote: »
    They aren't actually running GO on the Arduino. We really need a subset* of Firmata to run on the Propeller, that would open more doors of people wanting to interface PC and such to Propellers through Processing and other host based languages that talk to Firmata capable devices.

    I must admit my oversight - I didn't realize that they weren't running Go code on the microcontroller (but I see now from reading the code sample on the home page at gobot.io more carefully that yeah they are just connecting using Firmata).

    I agree, being able to fire up a Firmata ("server"?) in a cog and using that to drive the board from a high level language (on a PC of some sort) could be quite useful. It could also make for a cost effective way to build out more complex robotics where you need multiple boards for the additional IO pins, etc. Being able to do this in concert with code that is using other cogs would seem to be very useful as well - e.g. if you have a couple of software UARTs, each in a cog doing some kind of IO and yet as long as you have a free cog (or however many this would need - maybe two or three) you can still use that for the Firmata interface and shovel it additional things from the high level setup - that actually sounds quite useful.

    I wish I had time to devote to some dev on something like this (Firmata implementation in Spin/PropASM/C) - sounds like a lot of fun (and time consuming ;) If I find time to work on it, I'll definitely post an update.

    This link: http://ekpyroticfrood.net/?cat=2 appears to lead to some C code. Any suggestions on the best language to implement this in?
  • It's c for the Propeller. If you want an IDE, go over to the learn site and pick up SimpleIDE for your favorite PC platform. Ithe will install propgcc for you and you should be good to go. It is probably the easiest way to get propgcc installed even if you want to use it with your favorite editor instead of SimpleIDE.
    MOV OUTA, PEACE <div>Rick </div><div>"I've stopped using programming languages with Garbage Collection, they keep deleting my source code!!"</div>
  • jmgjmg Posts: 13,607
    bgp wrote: »
    I wish I had time to devote to some dev on something like this (Firmata implementation in Spin/PropASM/C) - sounds like a lot of fun (and time consuming ;) If I find time to work on it, I'll definitely post an update.

    This link: http://ekpyroticfrood.net/?cat=2 appears to lead to some C code. Any suggestions on the best language to implement this in?

    Some info is here
    https://github.com/firmata/protocol/blob/master/protocol.md
    https://github.com/firmata/protocol
    http://firmata.org/wiki/Main_Page

    Looks to use 57600 Baud, and MIDI variant
  • prof_brainoprof_braino Posts: 4,312
    edited 2016-06-19 - 16:59:08
    There is Go support already set up in propforth 5.5, with instructions.

    This is a Go language interface runs on the PC

    On the prop, the I/O is set up to "plug in" to the go interface using something similar to CSP channels. The fact that part lives on the PC and part lives on the prop is transparent to the programmer and the application (more or less).
    The result is that the PC sees cogs as just another group of tasks (that happen to be very fast at bit banging and primary filtering/processing), and the prop sees the PC as just another cog (that happens to support terminal services, communications, long term storage, and heavy secondary processing).

    The prop portion is all regular old propforth 5.5, which is ideally suited for bit banging, filtering and preprocessing the data streams to and from sensors and actuators.

    The example go setup is the propforth build and test automation. The default package instructions setup the build and test automation, and you can see the PC scripts generate a new forth kernel and execute the verification tests. Incidentally, the automation takes under two hours, whereas the manual testing took over two weeks last time we preformed it.

    To reiterate, no Go code run on the actual prop, that was found to be too cumbersome for the prop, and did not give anything or do anything better than propforth already provides. But this does allow us to do our drivers on the prop in forth (fast and easy ,a very efficient), and do whatever crunching on the PC, in Go or whatever on the PC.
Sign In or Register to comment.