[Timber] Re: platforms specification

[Ivan Tarasov]

Johan,

I'm fairly interested in the language and learning more about ARM. I could
help with porting/general improvements to Timber, however I would not want
the porting work I do to be useless for the future development (so doing
porting in my private branch which will never see the light of day because
the main branch is headed elsewhere or becomes too incompatible is the thing
I'd like to avoid). I know Haskell and have some experience in developing
real-time applications, so adding improvements should not be a problem.

I understand that there always be some hooks to specific hardware, even
after code reorganization, and that's why I'd like to see the “minimum
hardware requirements” and “target platform specifications” — so that it was
clear what are hard requirements and what could be worked around to make the
results work on a different, but close platform.

I'm not in an extreme hurry to make my project happen, however I want to
decide on a language/toolchain for it to start prototyping various things
using available hardware and/or ARM emulator.

On the other note, do you know any other practical research real-time
languages which I should look at (not as a matter of choosing one over
another, but to learn the new concepts which may be lacking from the
mainstream)?

Ivan

2009/10/5 Johan Nordlander <johan.nordlander at ltu.se>

> Hi Ivan,
>
> The only platform that is officially supported by the current release is
> POSIX, but an ARM port is indeed on its way.  However, as you have observed,
> the problem with our ARM prototype is that is is heavily linked to a very
> specific board with a very specific programming environment.  It would be so
> much better if an rts port could be made generic enough to work with any
> board matching some chosen architecture.
>
> Fortunately, our next compiler release will contain a slight code
> reorganization that makes an rts independent of the external environment one
> wishes to support.  For the ARM port this means that the interrupt vector
> table, the IO ports and the TFT driver will all be separate modules that one
> may choose to use on an individual basis, probably also combined with some
> form of parameterization regarding base addresses etc.  This will make
> adaption to a specific board like your ARM9 hardware much easier.
>
> However, even with such a reorganization there will still be some hardware
> dependencies left inside an rts like the ARM port: the timer interface being
> one, board and memory initialization being another.  Ideally such
> dependencies should also be singled out as separate modules for the benefit
> of easy rts adaption, although this time we're talking about C files, not
> Timber modules.  We're currently investigating how to do this the best way.
>
> All this is for the next release, though; sometime this fall.  So if you
> want to start your project today you'll probably have to do an adaption
> yourself, with a risk that the work will be overridden by the next release.
>  It shouldn't be too complicated, though, if you know your way with your
> hardware.  And we'll be interested in hearing about the results!
>
> Otherwise, stay tuned!
>
> -- Johan
>
>
>
>  Hello,
>>
>> is there some kind of description of Timber supported platforms? I can see
>> the ARM and POSIX platforms, and I can see that ARM is actually not just for
>> any ARM device, but the one with some kind of TFT (and probably other
>> hardware). What is exactly meant by ARM there?
>>
>>  I have a hobby project in mind, for which I'm likely to use ARM9 hardware
>> — does that mean that I'd need to create my own RTS (just like rtsARM and
>> rtsPOSIX in current sources)? Or should current ARM RTS be made more general
>> instead?
>>
>> Ivan
>> _______________________________________________
>> Timber mailing list
>> Timber at haskell.org
>> http://www.haskell.org/mailman/listinfo/timber
>>
>
> _______________________________________________
> Timber mailing list
> Timber at haskell.org
> http://www.haskell.org/mailman/listinfo/timber
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/timber/attachments/20091005/c69669d7/attachment.html