The code generator that 5g uses was originally developed for plan9 and
should be able to target quite old hardware. I've since introduced one
incompatibility by using strex/ldrex for cas but that's quite easy to
fix. A bigger deficiency is that there currently isn't soft float
support but you will be fine as long as you don't use floats. Soft
float support is planned but not yet done.
I've been looking at running on a AT91SAM7S256 which has 256Kb of
flash and 64Kb of ram. I'll try to shoehorn at least part of the
runtime into that space.
> It would be wonderful to have safer alternatives to C/C++ within the
> lower embedded markets?
Concur .. :-)
Kai
Usually, a good principle for small embedded systems is to not use
dynamic memory allocation. if so, you don't need malloc. It can be
hard to prove correctness of a program otherwise, with a small memory
availability.
That way you won't spend time doing garbage collection, another issue
if you want improved real-time.
I'm interested in the code density of the original T800 etc. It looked
excellent at the time, but compilers weren't that cunning back then.
Does anything related to the transterpreter universe let me compile C
for it with a good high-performance compiler? (C so that relatively
fair comparisons can be made with other ISAs). Details privately to
pe...@kivadesigngroupe.com, if so, please.
Thanks!
On Dec 11, 4:14 pm, Matt <jad...@gmail.com> wrote:
> On Dec 11, 8:31 am, roger peppe <rogpe...@gmail.com> wrote:
>
> > 2009/12/11 folknol...@googlemail.com <a...@folknology.com>:
> > that's interesting. very much occam-influenced.
>
> This is shameless self-promotion in a way, but it is on the thread of
> open (GPL/LGPL) CSP-based languages and runtimes in embedded spaces...
>
> A project I've contributed to (in the occam-related space) is theTransterpreterproject. It provides a portable bytecode interpreter
> for the occam-pi programming language. This January we'll be releasing
> full Arduino support. We've run on the H8, ARM, and a number of
> embedded platforms in the past.
>
> http://www.occam-pi.org/http://www.transterpreter.org/
>
> If you're looking for a way to do CSP-based programming in the
> embedded space, you might check out the project. We run everything but
> the dynamic elements of occam-pi in roughly 16K of flash (and a
> reasonably small number of words of RAM) on the Atmega328, and can run
> the full language on 32-bit platforms in not-much-more. Interrupts get
> latched in as waitable events, meaning you can easily set up interrupt-
> driven channels, etc.
>
> Arduino-related work will be released athttp://www.concurrency.cc/
Pete Wilson wrote: <<<Behind my mutterings on interrupts-by-messages was a desire to see better hardware (that is, hardware which thinks it's sending/receiving a message rather than "raising an interrupt" or "servicing an interrupt"), both in the processor and in "interrupt controllers", along with a much better programming paradigm. No interrupts, just messages. In both hardware and software.>>>
These are great ideas, but in embedded firmware, we're still grateful to C for rescuing us from the primordial assembler swamp! ;-) Is there any possibility of Go running in 32k of FLASH and 4 k of RAM? This would leave room for an application too, in the memory of some of the larger processors we deal with (e.g. 64k FLASH; 8 k RAM). When we can do that, I'll chat all day to you about message-passing, and other such sophistications. ;-)
"Who cares, wins"
I did try building the GCC version of go for the tiny avr architecture. I was able to get it built without go libraries
I did find dependencies with c header files to time.h and signal.h which are not really available in the architecture.
For a function with concurrency built into the language would it be able to run without the presence of these libraries and an operating system ?
Is there a way to get these features running in such architectures ?
--
Ilya
Ah, seems like a long-lived thread, though I'd pick-up. The headers like time.h are pretty easy to just implement, have you tried anything else since? It'd be great if you could provide some background to this... I was also thinking that running GC on a multicore MCU (e.g. LPC4350) would work, if we have pauseless GC.
A few weeks ago, I got to wondering what the smallest system that could usefully run Go programs was. Seems to be a 16-bit MCU; anything with less than about 16k of RAM probably isn’t adequately going to support the heap, though you might just possibly get away with 4k. I suppose the runtime would have to be extensively rewritten to fit, but I think it is possible. It would demand, I think, a considerably different coding style than is currently used in Go; any numeric type over 16 bits — that includes "rune!" — would carry a performance penalty.