Re: [Haskell-cafe] Does GHC 7.8 make targeting bare metal ARM any easier?

2013-03-20 Thread Karel Gardas


Hello Jeremy,

I'd also like to see GHC compiling for ARM bare metal. Honestly speaking 
I've avoided Raspberry Pi, but rather settled on ARMv7. Side note: 
BeagleBone is excellent for this as you get all the TI supported tools 
together with JTAG debugging just for free from TI (including ARM 
compilers if you care about this) and also you get full documentation 
for its Sitara 335x SoC.


Anyway, back to the GHC topic. I find it too invasive to go straight 
from POSIX/libc dependency to nothing on bare-metal. Instead of this 
while analyzing the situation for myself I've rather settled on POSIX 
RTOS which is much less weight that general purpose Linux distro and yet 
it provides a lot of API which makes GHC RTS porting work much easier.


So as my hobby time permits I'm working on GHC port to RTEMS[1] which is 
a single-process, multi-threaded RTOS with POSIX API supported. On its 
devel mailing list you may find that Raspberry Pi BSP was already 
submitted for inclusion. Generally speaking, I also hope that since this 
work is much less invasive on GHC, it has higher chance of a merge into 
GHC HEAD once ready...


Cheers,
Karel
[1]: http://www.rtems.org/

On 03/20/13 02:07 AM, Jeremy Shaw wrote:

There have been at least a couple projects, such as hOp and HaLVM
which attempt to run GHC on the bare metal or something similar.

Both these projects required a substantial set of patches against GHC
to remove dependencies things like POSIX/libc. Due to the highly
invasive nature, they are also highly prone to bitrot.

With GHC 7.8, I believe we will be able to cross-compile to the
Raspberry Pi platform. But, what really appeals to me is going that
extra step and avoiding the OS entirely and running on the bare metal.
Obviously, you give up a lot -- such as drivers, network stacks, etc.
But, there is also a lot of potential to do neat things, and not have
to worry about properly shutting down an embedded linux box.

Also, since the raspberry pi is a very limited, uniform platform,
(compared to general purpose PCs) it is feasible to create network
drivers, etc, because only one chipset needs to be supported.
(Ignoring issues regarding binary blobs, undocumented chipsets, usb
WIFI, etc).

I'm wondering if things are any easier with cross-compilation support
improving. My thought is that less of GHC needs to be tweaked?

- jeremy

___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Does GHC 7.8 make targeting bare metal ARM any easier?

2013-03-20 Thread John Meacham
kiwamu has been targeting an arm cortex-m3 succesfully with jhc. this
is a CPU with 40k of RAM running Haskell code very much on bare metal.
:)

John

On Tue, Mar 19, 2013 at 6:07 PM, Jeremy Shaw jer...@n-heptane.com wrote:
 There have been at least a couple projects, such as hOp and HaLVM
 which attempt to run GHC on the bare metal or something similar.

 Both these projects required a substantial set of patches against GHC
 to remove dependencies things like POSIX/libc. Due to the highly
 invasive nature, they are also highly prone to bitrot.

 With GHC 7.8, I believe we will be able to cross-compile to the
 Raspberry Pi platform. But, what really appeals to me is going that
 extra step and avoiding the OS entirely and running on the bare metal.
 Obviously, you give up a lot -- such as drivers, network stacks, etc.
 But, there is also a lot of potential to do neat things, and not have
 to worry about properly shutting down an embedded linux box.

 Also, since the raspberry pi is a very limited, uniform platform,
 (compared to general purpose PCs) it is feasible to create network
 drivers, etc, because only one chipset needs to be supported.
 (Ignoring issues regarding binary blobs, undocumented chipsets, usb
 WIFI, etc).

 I'm wondering if things are any easier with cross-compilation support
 improving. My thought is that less of GHC needs to be tweaked?

 - jeremy

 ___
 Glasgow-haskell-users mailing list
 glasgow-haskell-us...@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Does GHC 7.8 make targeting bare metal ARM any easier?

2013-03-20 Thread Magnus Therning
On Wed, Mar 20, 2013 at 08:05:04AM +0100, Karel Gardas wrote:
 
 Hello Jeremy,
 
 I'd also like to see GHC compiling for ARM bare metal. Honestly
 speaking I've avoided Raspberry Pi, but rather settled on ARMv7.
 Side note: BeagleBone is excellent for this as you get all the TI
 supported tools together with JTAG debugging just for free from TI
 (including ARM compilers if you care about this) and also you get
 full documentation for its Sitara 335x SoC.
 
 Anyway, back to the GHC topic. I find it too invasive to go straight
 from POSIX/libc dependency to nothing on bare-metal. Instead of this
 while analyzing the situation for myself I've rather settled on
 POSIX RTOS which is much less weight that general purpose Linux
 distro and yet it provides a lot of API which makes GHC RTS porting
 work much easier.
 
 So as my hobby time permits I'm working on GHC port to RTEMS[1]
 which is a single-process, multi-threaded RTOS with POSIX API
 supported. On its devel mailing list you may find that Raspberry Pi
 BSP was already submitted for inclusion. Generally speaking, I also
 hope that since this work is much less invasive on GHC, it has
 higher chance of a merge into GHC HEAD once ready...

This is exactly what I've been telling my colleagues (who like me
mostly are stuck working with C on embedded devices) is what we
*really* ought to be doing. :)

Is there anything I can do to help out?
Are you doing this work in the open?
Can I find the code somewhere?

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus


Perl is another example of filling a tiny, short-term need, and then
being a real problem in the longer term.
 -- Alan Kay

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Does GHC 7.8 make targeting bare metal ARM any easier?

2013-03-19 Thread Jeremy Shaw
There have been at least a couple projects, such as hOp and HaLVM
which attempt to run GHC on the bare metal or something similar.

Both these projects required a substantial set of patches against GHC
to remove dependencies things like POSIX/libc. Due to the highly
invasive nature, they are also highly prone to bitrot.

With GHC 7.8, I believe we will be able to cross-compile to the
Raspberry Pi platform. But, what really appeals to me is going that
extra step and avoiding the OS entirely and running on the bare metal.
Obviously, you give up a lot -- such as drivers, network stacks, etc.
But, there is also a lot of potential to do neat things, and not have
to worry about properly shutting down an embedded linux box.

Also, since the raspberry pi is a very limited, uniform platform,
(compared to general purpose PCs) it is feasible to create network
drivers, etc, because only one chipset needs to be supported.
(Ignoring issues regarding binary blobs, undocumented chipsets, usb
WIFI, etc).

I'm wondering if things are any easier with cross-compilation support
improving. My thought is that less of GHC needs to be tweaked?

- jeremy

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe