Re: Does GHC 7.8 make targeting bare metal ARM any easier?
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 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-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Does GHC 7.8 make targeting bare metal ARM any easier?
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-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Does GHC 7.8 make targeting bare metal ARM any easier?
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-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
