Pandora Wiki - User contributions [en]

Software projects

2009-10-22T06:48:03Z

Adventus: /* Games */

See the [[Port Requests]] article for open-source projects which ''could'' be ported but have not been taken on by anyone yet.

== Operating Systems ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Android Omap
|[http://elinux.org/Android_on_OMAP Link]
|wip
|
|
|-
|Angstrom Linux
|[http://www.angstrom-distribution.org/ Link]
|Working build, not completed
|
|
|-
|AROS Arm
|[http://projects.powerdeveloper.org/project/imx515/735 Link]
|wip
|
|
|-
|FreeBSD
|[http://wiki.freebsd.org/FreeBSD/arm/OMAP Link]
|wip
|
|
|-
|Gentoo Linux
|[http://gentoo.openpandora.org Link]
|Working build, not completed
|javaJake, Viridior
|IRC: (FreeNode) #gentoo-pandora
|-
|HaikuOS
|[http://www.haiku-os.org Link]
|wip
|
|
|-
|Ubuntu ARM
|[http://www.ubuntu.com/products/whatisubuntu/arm Link]
|wip
|
|
|-
|Fedora ARM
|
|Unknown
|
|
|}

== Games ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Abuse
|[http://abuse.zoy.org/ Link]
|working build
|Cpasjuste
|2D Platform
|-
|Battle for Wesnoth v1.6.2
|[http://www.gp32x.com/board/index.php?showtopic=47936 Link]
|working build
|Cpasjuste
|Strategy
|-
|BattleJewels
|
|Completed build for GP2X, WIP for Pandora
|Skeezix
|Logical
|-
|BlobWars
|[http://www.parallelrealities.co.uk/projects/blobWars.php Link]
|working build
|Cpasjuste
|2D Platform
|-
|Caster
|[http://www.gp32x.com/board/index.php?showtopic=46813 Link]
|Working build (tested on PC)
|Svartalf
|RPG
|-
|Chaotic Vortex
|[http://www.gp32x.com/board/index.php?/topic/49754-chaotic-vortex-dual-stick-arena-shooter Link]
|WIP
|Ruben
|Dual stick 2D shooter
|-
|Descent 1 (d1x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|Descent 2 (d2x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|FHeroes Port (Heroes Of Might And Magic 2)
|[http://www.gp32x.com/board/index.php?showtopic=47553 Link]
|Working build
|Pickle
|Strategy
|-
|FreeCiv 2.1.9
|[http://freeciv.wikia.com/wiki/Main_Page Link]
|Working build
|Cpasjuste
|Strategy
|-
|Galactic Artifact
|[http://www.gp32x.com/board/index.php?showtopic=46836 Link]
|Working build
|Trevor Bradley
|Strategy
|-
|GemRB (Infinity Engine)
|
|wip
|Adventus
|open-source implementation of Bioware's Infinity Engine, supports games including Baldurs Gate 2 and Planescape Torment.
|-
|Giannas Return
|[http://www.gianas-return.de/ Link]
|Working
|Giannas Team
|Arcade
|-
|Gravity Blocks
|[http://www.gp32x.com/board/index.php?showtopic=47662 Link]
|wip (early in developement)
|Awekening
|Arcade
|-
|Homeworld Port
|[http://www.gp32x.com/board/index.php?showtopic=47565 Link]
|wip
|LinuxHacker
|Simulation
|-
|Human Condition (was TINCS)
|[http://www.gp32x.com/board/index.php?showtopic=46487 Link1][http://www.youtube.com/user/ButtermanHimself Link2]
|wip
|Butterman
|FPP
|-
|Lerp
|[http://grapefruitopia.com/lerp/ Link]
|working build
|benjymous
|2D physics puzzle platformer
|-
|Lord of the Rings Port
|[http://www.gp32x.com/board/index.php?showtopic=46792&hl= Link]
|Unknown
|Daeglin
|RPG
|-
|Mental
|
|Working build, tested on PC
|Colin Jones (xentalion)
|2D Horror Survival Adventure
|-
|Monster!
|[http://christophsdevblog.blogspot.com/ Link]
|wip
|Chris R
|Arcade
|-
|NAEV
|[http://code.google.com/p/naev/ Link]
|wip (waiting for pandora to finish and test)
|bobbens
|Action/RPG/Sim
|-
|Nails Adventure
|[http://www.gp32x.com/board/index.php?showtopic=46961 Link]
|wip
|jsmtux/Mr. Gonzo
|
|-
|OpenLiero (Liero)
|
|working build, need to be polished
|Pickle
|Shoot'Em Up
|-
|OpenTyrian
|[http://code.google.com/p/opentyrian/ Link]
|working build
|Cpasjuste
|Shoot'Em Up
|-
|Pandora Panic!
|[http://www.youtube.com/watch?v=y9d6UXhQP6o Link]
|Working build
|PokeParadox / GP32X Community
|Arcade
|-
|Pandora Pool Panic
|[http://www.gp32x.com/board/index.php?showtopic=46996 Link]
|Almost Finished
|Unfathomable Depths
|Arcade
|-
|PanMMO - Pandora MMO Game via Internet
|[http://www.youtube.com/user/enirya Link]
|wip
|Enirya
|RPG
|-
|Powermanga
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Quake 1
|
|working build
|Pickle
|FPP
|-
|Quake 2
|
|working build
|Pickle
|FPP
|-
|Quake 3
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|FPP
|-
|Quake 3
|
|working build
|Pickle
|FPP
|-
|Reminiscence (flashback)
|[http://cyxdown.free.fr/reminiscence/ Link]
|working build
|Cpasjuste
|Action/Adventure
|-
|Rise of The Triad
|[http://www.gp32x.com/board/index.php?showtopic=47931 Link]
|wip
|arrrgh
|FPP
|-
|Stratagus
|[http://stratagus.sourceforge.net/ Link]
|working build
|Cpasjuste
|RTS Engine
|-
|Super Lumenal
|[http://www.youtube.com/watch?v=sZHi3YT3xuE&feature=channel_page Link]
|wip
|Adventus
|Arcade
|-
|SuperTux 1
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|SuperTux 2
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|Tecnoballz
|[http://mydedibox.fr/_stuff/pandora/ Link]
|Working build
|Cpasjuste
|
|-
|Teeworlds
|[http://www.teeworlds.com/ Link]
|wip
|
|Arcade
|-
|The Mana World
|[http://www.themanaworld.org/ Link]
|Working build
|Cpasjuste
|MMORPG
|-
|uHexen2: Hammer of Thyrion
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Ur-Quan Masters
|[http://www.gp32x.com/board/index.php?showtopic=43625&st=165&p=673047&#entry673047 Link]
|Working build
|
|Space Exploration
|-
|Warioland-inspired game
|[http://www.gp32x.com/board/index.php?/topic/48680-warioland-inspired-game/ Link]
|wip
|foxblock
|Platformer
|-
|We Come In Peace
|[http://www.gp32x.com/board/index.php?showtopic=43655 Link]
|working build
|Otaco
|Strategy
|-
|Where in world is...
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|Casual
|-
|Wizzley Presto and the Mysterious Time Machine
|[http://www.30daygame.com/ Link]
|wip
|Craigix, Zodttd, Ruckage
|Arcade, 30 Day Game Competition
|-
|Wolf4SDL (Wolfenstein 3D)
|
|working build
|Pickle
|FPP
|-
|XSwing Plus
|[http://www.gp32x.com/board/index.php?s=&showtopic=43655&view=findpost&p=733021 Link]
|wip
|Tobse
|Arcade
|-
|ZEQ2Lite
|[http://www.gp32x.com/board/index.php?showtopic=47623&hl= Link]
|Work in progress
|MDave
|Dragonball Z Third Person Fighter/Shooter
|-
|Zdoom
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Zombd
|[http://www.gp32x.com/board/index.php?showtopic=46933 Link]
|Wip
|iprice/Mr Gonzo
|Shoot'Em Up
|}

== Emulators ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Emulated System
! Link
! Status
! Author/Port Author
! Notes
|-
|Caprice32
|Amstrad CPC
|[http://www.gp32x.com/board/index.php?showtopic=48140 Link1] [http://www.caprice32.cybercube.com/ Link2]
|wip
|hdonk
|
|-
|DosBox
|x86 DOS
|
|working build
|Pickle
|
|-
|FinalBurnAdvance
|CPS1/2/3/taito...
|[http://www.youtube.com/watch?v=06hjDLMBaf8 Link]
|
|Squidge
|
|-
|Frotz
|Z-Machine interpreter
|[http://www.cosam.org/computers/pandora/frotz-2.43.zip Link]
|working build
|SteveM
|
|-
|Fuse
|ZX Spectrum
|[http://www.cosam.org/computers/pandora/fuse-0.9.0.zip Link]
|working build
|SteveM
|
|-
|GnGeo
|SNK NeoGeo
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|gpSP
|Nintendo GBA
|
|wip
|ZodTTD
|
|-
|Hatari
|Atari ST
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|Jzintv
|Mattel Intellivision
|[http://www.gp32x.com/board/index.php?showtopic=48035 Link]
|
|WizardStan
|
|-
|MAME4All
|Arcade
|[http://www.youtube.com/user/franxism Link]
|
|Franxis
|
|-
|Mupen64plus
|Nintendo 64
|[http://www.gp32x.com/board/index.php?/topic/49358-mupen64plus/ Link]
|working build
|Ari64
|Adventus ported graphics plugin
|-
|NeoPop
|SNK NeoGeo Pocket
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|NullDC
|Sega Dreamcast
|[http://www.gp32x.com/board/index.php?s=&showtopic=47065&view=findpost&p=709910 Link]
|Wip
|Zezu / drkIIraziel
|
|-
|PandaSNES
|Nintendo SNES
|[http://www.gp32x.com/board/index.php?showtopic=43213 Link]
|wip
|Squidge
|
|-
|Pandora-PSP
|Sony Playstation Portable
|[http://jayfoxrox.bplaced.net/pandora-psp/ Link]
|wip
|[[User:JayFoxRox|JayFoxRox]]
|
|-
|PAtari
|Atari 800
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PicoDrive
|Sega Genesis/CD/32x
|[http://www.youtube.com/watch?v=QDbLQI91510 Link]
|working build
|Notaz
|Fullspeed emulator
|-
|PSMS
|Sega Master System
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PSnes
|Nintendo SNES
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Psx4All
|Sony PlayStation
|[http://www.zodttd.com Link]
|Not Status, working build
|ZodTTD
|
|-
|ScummVM
|x86 Scumm engine games
|
|Working build
|DJ Willis
|Fullspeed emulator
|-
|SIMH
|old hardware
|[http://www.cosam.org/computers/pandora/simh-3.8.zip Link]
|working build
|SteveM
|
|-
|Temper
|NEC PC Engine
|[http://exophase.devzero.co.uk/ Link]
|wip
|Exophase
|Fullspeed emulator
|-
|Tempest
|Atari Jaguar
|[http://www.gp32x.com/board/index.php?showtopic=43119 Link]
|
|Firefox
|
|-
|Uae4All
|Amiga
|[http://www.gp32x.com/board/index.php?showtopic=44100 Link]
|Working build
|
|
|-
|XMAME
|Arcade
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|}

== Graphic Engines ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|GLES2D
|
|Wip
|Cpasjuste
|OpenGL ES 2D library
|-
|GL-WES-v2.0
|[http://code.google.com/p/gl-wes-v2/ link]
|Working Build
|Adventus
|Opensource OpenGL 2.0 driver built on OpenGL ES 2.0.
|-
|Irrlicht
|[http://irrlicht.sourceforge.net/] [http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=32538&start=45]
|working build
|Hybrid
|3D game engine
|-
|NSS Engine
|[http://www.nosiestastudios.com/wiki/ Link1] [http://www.youtube.com/user/Prompt84 Link2]
|
|No Siesta Studios
|
|-
|OGRE Engine
|[http://www.gp32x.com/board/index.php?showtopic=46706 Link1] [http://www.youtube.com/watch?v=LDtUE5PIhV0 Link2]
|
|
|3D real-time renderer
|-
|Otaco Glost Engine
|[http://www.youtube.com/user/otacogloost Link1], [http://www.gp32x.com/board/index.php?/topic/48393-i-did-stuff/page__p__736650&#entry736650 Link2]
|working
|Otaco
|
|-
|Quad-Ren 2D
|[http://quad-ren.sourceforge.net/index.php Link]
|
|Hessiess
|
|-
|SDL GLES
|[http://github.com/Cpasjuste/sdl-1.2.13_gles/tree Link]
|working
|Cpasjuste
|
|-
|XreaL
|[http://xreal.sourceforge.net/xrealwiki/ Link]
|
|Pickle [?]
|
|}

== Other programs ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|AbiWord - Word Processor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Claws Mail
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Epiphany Web Bowser
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|FireFox - Internet Browser
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GIMP - Image Editor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GMenu
|[http://www.youtube.com/watch?v=VYzi8gziC7E Link]
|Working build
|Pandora Team
|
|-
|Gnumeric Spreadsheet - Spreadsheet
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GoView
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Image Gallery
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Inside The Box
|[http://www.openpandora.pl Link1] [http://www.youtube.com/watch?v=uLMmJBDEs2E Link2]
|wip
|StreaK
|Pandora e-zine
|-
|IRC Client
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|LeafPad
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Matchbox Shell / GUI
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|MPlayer
|[http://www.gp32x.com/board/index.php?showtopic=41420 Link1] [http://www.youtube.com/watch?v=v9RAPNa-55k Link2]
|Working build
|Squidge
|
|-
|Math-NEON
|[http://code.google.com/p/math-neon/ Link1]
|Wip
|Adventus
|cmath like library optimised for ARM NEON coprocessor.
|-
|Pandaphone
|[http://www.gp32x.com/board/index.php?/topic/48327-pandaphone/ Link]
|
|jb0yx
|A project to incorporate the Open Pandora handheld device with cell phone technology
|-
|Pandora Sync Suite
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|for Windows 9x/NT
|-
|Pangea GUI
|[http://www.gp32x.com/board/index.php?showtopic=45631&hl=pangea Link]
|WIP
|efegea
|Gmenu alternative
|-
|PDM
|[http://github.com/Cpasjuste/pdm/tree Link]
|
|Cpasjuste
|Light desktop manager for Pandora
|-
|PGui
|[http://github.com/Cpasjuste/pgui/tree Link]
|
|Cpasjuste
|Standard emulator fronted for Pandora
|-
|Pidgin - IM (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|PMenu
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|Minimal Menu for Pandora
|-
|PND Maker (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Qemu
|[http://www.nongnu.org/qemu/status.html Link]
|testing build
|Fabrice Bellard
|open source machine emulator and virtualizer
|-
|Scale
|[http://www.youtube.com/user/Zoxc64 Link]
|wip
|Zoxc64
|Minimal Menu for Pandora
|-
|Simple Dev Studio for Pandora
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|for Windows 9x/NT
|-
|[[TINXL]]
|[[TINXL]]
|
|
|Application stack for multiplayer internet games
|-
|[[TS2A]]
|[[TS2A]]
|Documentation only
||[[User:JayFoxRox|JayFoxRox]]
|Teamspeak 2 Alternative Client / Server, Needs developer
|-
|XMMS
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|ZiB Emulator Frontend
|[http://www.gp32x.com/board/index.php?showtopic=47203 Link1] [http://www.youtube.com/watch?v=UJvON8lCM3M Link2]
|
|Aimless_E
|
|}

== Demos / Technical Demos for OpenPandora ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|OpenGL Cell Shading
|[http://www.youtube.com/watch?v=cpAj0jHglGw Link]
|working build
|
|
|-
|OpenGL Demo with MP3 Playback
|[http://www.youtube.com/watch?v=hkx18kruRJs Link]
|working build
|
|
|-
|OpenGL Skull Demo
|[http://www.youtube.com/watch?v=qG7EDaZpyOo Link]
|working build
|
|
|-
|WaveDemo
|[http://www.youtube.com/watch?v=4wgEHFCq9Lo Link]
|Working
|Otaco
|
|}

Software projects

2009-10-22T06:47:00Z

Adventus: /* Graphic Engines */

See the [[Port Requests]] article for open-source projects which ''could'' be ported but have not been taken on by anyone yet.

== Operating Systems ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Android Omap
|[http://elinux.org/Android_on_OMAP Link]
|wip
|
|
|-
|Angstrom Linux
|[http://www.angstrom-distribution.org/ Link]
|Working build, not completed
|
|
|-
|AROS Arm
|[http://projects.powerdeveloper.org/project/imx515/735 Link]
|wip
|
|
|-
|FreeBSD
|[http://wiki.freebsd.org/FreeBSD/arm/OMAP Link]
|wip
|
|
|-
|Gentoo Linux
|[http://gentoo.openpandora.org Link]
|Working build, not completed
|javaJake, Viridior
|IRC: (FreeNode) #gentoo-pandora
|-
|HaikuOS
|[http://www.haiku-os.org Link]
|wip
|
|
|-
|Ubuntu ARM
|[http://www.ubuntu.com/products/whatisubuntu/arm Link]
|wip
|
|
|-
|Fedora ARM
|
|Unknown
|
|
|}

== Games ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Abuse
|[http://abuse.zoy.org/ Link]
|working build
|Cpasjuste
|2D Platform
|-
|Battle for Wesnoth v1.6.2
|[http://www.gp32x.com/board/index.php?showtopic=47936 Link]
|working build
|Cpasjuste
|Strategy
|-
|BattleJewels
|
|Completed build for GP2X, WIP for Pandora
|Skeezix
|Logical
|-
|BlobWars
|[http://www.parallelrealities.co.uk/projects/blobWars.php Link]
|working build
|Cpasjuste
|2D Platform
|-
|Caster
|[http://www.gp32x.com/board/index.php?showtopic=46813 Link]
|Working build (tested on PC)
|Svartalf
|RPG
|-
|Chaotic Vortex
|[http://www.gp32x.com/board/index.php?/topic/49754-chaotic-vortex-dual-stick-arena-shooter Link]
|WIP
|Ruben
|Dual stick 2D shooter
|-
|Descent 1 (d1x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|Descent 2 (d2x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|FHeroes Port (Heroes Of Might And Magic 2)
|[http://www.gp32x.com/board/index.php?showtopic=47553 Link]
|Working build
|Pickle
|Strategy
|-
|FreeCiv 2.1.9
|[http://freeciv.wikia.com/wiki/Main_Page Link]
|Working build
|Cpasjuste
|Strategy
|-
|Galactic Artifact
|[http://www.gp32x.com/board/index.php?showtopic=46836 Link]
|Working build
|Trevor Bradley
|Strategy
|-
|Giannas Return
|[http://www.gianas-return.de/ Link]
|Working
|Giannas Team
|Arcade
|-
|Gravity Blocks
|[http://www.gp32x.com/board/index.php?showtopic=47662 Link]
|wip (early in developement)
|Awekening
|Arcade
|-
|Homeworld Port
|[http://www.gp32x.com/board/index.php?showtopic=47565 Link]
|wip
|LinuxHacker
|Simulation
|-
|Human Condition (was TINCS)
|[http://www.gp32x.com/board/index.php?showtopic=46487 Link1][http://www.youtube.com/user/ButtermanHimself Link2]
|wip
|Butterman
|FPP
|-
|Lerp
|[http://grapefruitopia.com/lerp/ Link]
|working build
|benjymous
|2D physics puzzle platformer
|-
|Lord of the Rings Port
|[http://www.gp32x.com/board/index.php?showtopic=46792&hl= Link]
|Unknown
|Daeglin
|RPG
|-
|Mental
|
|Working build, tested on PC
|Colin Jones (xentalion)
|2D Horror Survival Adventure
|-
|Monster!
|[http://christophsdevblog.blogspot.com/ Link]
|wip
|Chris R
|Arcade
|-
|NAEV
|[http://code.google.com/p/naev/ Link]
|wip (waiting for pandora to finish and test)
|bobbens
|Action/RPG/Sim
|-
|Nails Adventure
|[http://www.gp32x.com/board/index.php?showtopic=46961 Link]
|wip
|jsmtux/Mr. Gonzo
|
|-
|OpenLiero (Liero)
|
|working build, need to be polished
|Pickle
|Shoot'Em Up
|-
|OpenTyrian
|[http://code.google.com/p/opentyrian/ Link]
|working build
|Cpasjuste
|Shoot'Em Up
|-
|Pandora Panic!
|[http://www.youtube.com/watch?v=y9d6UXhQP6o Link]
|Working build
|PokeParadox / GP32X Community
|Arcade
|-
|Pandora Pool Panic
|[http://www.gp32x.com/board/index.php?showtopic=46996 Link]
|Almost Finished
|Unfathomable Depths
|Arcade
|-
|PanMMO - Pandora MMO Game via Internet
|[http://www.youtube.com/user/enirya Link]
|wip
|Enirya
|RPG
|-
|Powermanga
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Quake 1
|
|working build
|Pickle
|FPP
|-
|Quake 2
|
|working build
|Pickle
|FPP
|-
|Quake 3
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|FPP
|-
|Quake 3
|
|working build
|Pickle
|FPP
|-
|Reminiscence (flashback)
|[http://cyxdown.free.fr/reminiscence/ Link]
|working build
|Cpasjuste
|Action/Adventure
|-
|Rise of The Triad
|[http://www.gp32x.com/board/index.php?showtopic=47931 Link]
|wip
|arrrgh
|FPP
|-
|Stratagus
|[http://stratagus.sourceforge.net/ Link]
|working build
|Cpasjuste
|RTS Engine
|-
|Super Lumenal
|[http://www.youtube.com/watch?v=sZHi3YT3xuE&feature=channel_page Link]
|wip
|Adventus
|Arcade
|-
|SuperTux 1
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|SuperTux 2
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|Tecnoballz
|[http://mydedibox.fr/_stuff/pandora/ Link]
|Working build
|Cpasjuste
|
|-
|Teeworlds
|[http://www.teeworlds.com/ Link]
|wip
|
|Arcade
|-
|The Mana World
|[http://www.themanaworld.org/ Link]
|Working build
|Cpasjuste
|MMORPG
|-
|uHexen2: Hammer of Thyrion
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Ur-Quan Masters
|[http://www.gp32x.com/board/index.php?showtopic=43625&st=165&p=673047&#entry673047 Link]
|Working build
|
|Space Exploration
|-
|Warioland-inspired game
|[http://www.gp32x.com/board/index.php?/topic/48680-warioland-inspired-game/ Link]
|wip
|foxblock
|Platformer
|-
|We Come In Peace
|[http://www.gp32x.com/board/index.php?showtopic=43655 Link]
|working build
|Otaco
|Strategy
|-
|Where in world is...
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|Casual
|-
|Wizzley Presto and the Mysterious Time Machine
|[http://www.30daygame.com/ Link]
|wip
|Craigix, Zodttd, Ruckage
|Arcade, 30 Day Game Competition
|-
|Wolf4SDL (Wolfenstein 3D)
|
|working build
|Pickle
|FPP
|-
|XSwing Plus
|[http://www.gp32x.com/board/index.php?s=&showtopic=43655&view=findpost&p=733021 Link]
|wip
|Tobse
|Arcade
|-
|ZEQ2Lite
|[http://www.gp32x.com/board/index.php?showtopic=47623&hl= Link]
|Work in progress
|MDave
|Dragonball Z Third Person Fighter/Shooter
|-
|Zdoom
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Zombd
|[http://www.gp32x.com/board/index.php?showtopic=46933 Link]
|Wip
|iprice/Mr Gonzo
|Shoot'Em Up
|}

== Emulators ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Emulated System
! Link
! Status
! Author/Port Author
! Notes
|-
|Caprice32
|Amstrad CPC
|[http://www.gp32x.com/board/index.php?showtopic=48140 Link1] [http://www.caprice32.cybercube.com/ Link2]
|wip
|hdonk
|
|-
|DosBox
|x86 DOS
|
|working build
|Pickle
|
|-
|FinalBurnAdvance
|CPS1/2/3/taito...
|[http://www.youtube.com/watch?v=06hjDLMBaf8 Link]
|
|Squidge
|
|-
|Frotz
|Z-Machine interpreter
|[http://www.cosam.org/computers/pandora/frotz-2.43.zip Link]
|working build
|SteveM
|
|-
|Fuse
|ZX Spectrum
|[http://www.cosam.org/computers/pandora/fuse-0.9.0.zip Link]
|working build
|SteveM
|
|-
|GnGeo
|SNK NeoGeo
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|gpSP
|Nintendo GBA
|
|wip
|ZodTTD
|
|-
|Hatari
|Atari ST
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|Jzintv
|Mattel Intellivision
|[http://www.gp32x.com/board/index.php?showtopic=48035 Link]
|
|WizardStan
|
|-
|MAME4All
|Arcade
|[http://www.youtube.com/user/franxism Link]
|
|Franxis
|
|-
|Mupen64plus
|Nintendo 64
|[http://www.gp32x.com/board/index.php?/topic/49358-mupen64plus/ Link]
|working build
|Ari64
|Adventus ported graphics plugin
|-
|NeoPop
|SNK NeoGeo Pocket
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|NullDC
|Sega Dreamcast
|[http://www.gp32x.com/board/index.php?s=&showtopic=47065&view=findpost&p=709910 Link]
|Wip
|Zezu / drkIIraziel
|
|-
|PandaSNES
|Nintendo SNES
|[http://www.gp32x.com/board/index.php?showtopic=43213 Link]
|wip
|Squidge
|
|-
|Pandora-PSP
|Sony Playstation Portable
|[http://jayfoxrox.bplaced.net/pandora-psp/ Link]
|wip
|[[User:JayFoxRox|JayFoxRox]]
|
|-
|PAtari
|Atari 800
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PicoDrive
|Sega Genesis/CD/32x
|[http://www.youtube.com/watch?v=QDbLQI91510 Link]
|working build
|Notaz
|Fullspeed emulator
|-
|PSMS
|Sega Master System
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PSnes
|Nintendo SNES
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Psx4All
|Sony PlayStation
|[http://www.zodttd.com Link]
|Not Status, working build
|ZodTTD
|
|-
|ScummVM
|x86 Scumm engine games
|
|Working build
|DJ Willis
|Fullspeed emulator
|-
|SIMH
|old hardware
|[http://www.cosam.org/computers/pandora/simh-3.8.zip Link]
|working build
|SteveM
|
|-
|Temper
|NEC PC Engine
|[http://exophase.devzero.co.uk/ Link]
|wip
|Exophase
|Fullspeed emulator
|-
|Tempest
|Atari Jaguar
|[http://www.gp32x.com/board/index.php?showtopic=43119 Link]
|
|Firefox
|
|-
|Uae4All
|Amiga
|[http://www.gp32x.com/board/index.php?showtopic=44100 Link]
|Working build
|
|
|-
|XMAME
|Arcade
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|}

== Graphic Engines ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|GLES2D
|
|Wip
|Cpasjuste
|OpenGL ES 2D library
|-
|GL-WES-v2.0
|[http://code.google.com/p/gl-wes-v2/ link]
|Working Build
|Adventus
|Opensource OpenGL 2.0 driver built on OpenGL ES 2.0.
|-
|Irrlicht
|[http://irrlicht.sourceforge.net/] [http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=32538&start=45]
|working build
|Hybrid
|3D game engine
|-
|NSS Engine
|[http://www.nosiestastudios.com/wiki/ Link1] [http://www.youtube.com/user/Prompt84 Link2]
|
|No Siesta Studios
|
|-
|OGRE Engine
|[http://www.gp32x.com/board/index.php?showtopic=46706 Link1] [http://www.youtube.com/watch?v=LDtUE5PIhV0 Link2]
|
|
|3D real-time renderer
|-
|Otaco Glost Engine
|[http://www.youtube.com/user/otacogloost Link1], [http://www.gp32x.com/board/index.php?/topic/48393-i-did-stuff/page__p__736650&#entry736650 Link2]
|working
|Otaco
|
|-
|Quad-Ren 2D
|[http://quad-ren.sourceforge.net/index.php Link]
|
|Hessiess
|
|-
|SDL GLES
|[http://github.com/Cpasjuste/sdl-1.2.13_gles/tree Link]
|working
|Cpasjuste
|
|-
|XreaL
|[http://xreal.sourceforge.net/xrealwiki/ Link]
|
|Pickle [?]
|
|}

== Other programs ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|AbiWord - Word Processor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Claws Mail
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Epiphany Web Bowser
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|FireFox - Internet Browser
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GIMP - Image Editor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GMenu
|[http://www.youtube.com/watch?v=VYzi8gziC7E Link]
|Working build
|Pandora Team
|
|-
|Gnumeric Spreadsheet - Spreadsheet
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GoView
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Image Gallery
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Inside The Box
|[http://www.openpandora.pl Link1] [http://www.youtube.com/watch?v=uLMmJBDEs2E Link2]
|wip
|StreaK
|Pandora e-zine
|-
|IRC Client
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|LeafPad
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Matchbox Shell / GUI
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|MPlayer
|[http://www.gp32x.com/board/index.php?showtopic=41420 Link1] [http://www.youtube.com/watch?v=v9RAPNa-55k Link2]
|Working build
|Squidge
|
|-
|Math-NEON
|[http://code.google.com/p/math-neon/ Link1]
|Wip
|Adventus
|cmath like library optimised for ARM NEON coprocessor.
|-
|Pandaphone
|[http://www.gp32x.com/board/index.php?/topic/48327-pandaphone/ Link]
|
|jb0yx
|A project to incorporate the Open Pandora handheld device with cell phone technology
|-
|Pandora Sync Suite
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|for Windows 9x/NT
|-
|Pangea GUI
|[http://www.gp32x.com/board/index.php?showtopic=45631&hl=pangea Link]
|WIP
|efegea
|Gmenu alternative
|-
|PDM
|[http://github.com/Cpasjuste/pdm/tree Link]
|
|Cpasjuste
|Light desktop manager for Pandora
|-
|PGui
|[http://github.com/Cpasjuste/pgui/tree Link]
|
|Cpasjuste
|Standard emulator fronted for Pandora
|-
|Pidgin - IM (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|PMenu
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|Minimal Menu for Pandora
|-
|PND Maker (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Qemu
|[http://www.nongnu.org/qemu/status.html Link]
|testing build
|Fabrice Bellard
|open source machine emulator and virtualizer
|-
|Scale
|[http://www.youtube.com/user/Zoxc64 Link]
|wip
|Zoxc64
|Minimal Menu for Pandora
|-
|Simple Dev Studio for Pandora
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|for Windows 9x/NT
|-
|[[TINXL]]
|[[TINXL]]
|
|
|Application stack for multiplayer internet games
|-
|[[TS2A]]
|[[TS2A]]
|Documentation only
||[[User:JayFoxRox|JayFoxRox]]
|Teamspeak 2 Alternative Client / Server, Needs developer
|-
|XMMS
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|ZiB Emulator Frontend
|[http://www.gp32x.com/board/index.php?showtopic=47203 Link1] [http://www.youtube.com/watch?v=UJvON8lCM3M Link2]
|
|Aimless_E
|
|}

== Demos / Technical Demos for OpenPandora ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|OpenGL Cell Shading
|[http://www.youtube.com/watch?v=cpAj0jHglGw Link]
|working build
|
|
|-
|OpenGL Demo with MP3 Playback
|[http://www.youtube.com/watch?v=hkx18kruRJs Link]
|working build
|
|
|-
|OpenGL Skull Demo
|[http://www.youtube.com/watch?v=qG7EDaZpyOo Link]
|working build
|
|
|-
|WaveDemo
|[http://www.youtube.com/watch?v=4wgEHFCq9Lo Link]
|Working
|Otaco
|
|}

Software projects

2009-10-22T06:45:04Z

Adventus: /* Emulators */

See the [[Port Requests]] article for open-source projects which ''could'' be ported but have not been taken on by anyone yet.

== Operating Systems ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Android Omap
|[http://elinux.org/Android_on_OMAP Link]
|wip
|
|
|-
|Angstrom Linux
|[http://www.angstrom-distribution.org/ Link]
|Working build, not completed
|
|
|-
|AROS Arm
|[http://projects.powerdeveloper.org/project/imx515/735 Link]
|wip
|
|
|-
|FreeBSD
|[http://wiki.freebsd.org/FreeBSD/arm/OMAP Link]
|wip
|
|
|-
|Gentoo Linux
|[http://gentoo.openpandora.org Link]
|Working build, not completed
|javaJake, Viridior
|IRC: (FreeNode) #gentoo-pandora
|-
|HaikuOS
|[http://www.haiku-os.org Link]
|wip
|
|
|-
|Ubuntu ARM
|[http://www.ubuntu.com/products/whatisubuntu/arm Link]
|wip
|
|
|-
|Fedora ARM
|
|Unknown
|
|
|}

== Games ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Abuse
|[http://abuse.zoy.org/ Link]
|working build
|Cpasjuste
|2D Platform
|-
|Battle for Wesnoth v1.6.2
|[http://www.gp32x.com/board/index.php?showtopic=47936 Link]
|working build
|Cpasjuste
|Strategy
|-
|BattleJewels
|
|Completed build for GP2X, WIP for Pandora
|Skeezix
|Logical
|-
|BlobWars
|[http://www.parallelrealities.co.uk/projects/blobWars.php Link]
|working build
|Cpasjuste
|2D Platform
|-
|Caster
|[http://www.gp32x.com/board/index.php?showtopic=46813 Link]
|Working build (tested on PC)
|Svartalf
|RPG
|-
|Chaotic Vortex
|[http://www.gp32x.com/board/index.php?/topic/49754-chaotic-vortex-dual-stick-arena-shooter Link]
|WIP
|Ruben
|Dual stick 2D shooter
|-
|Descent 1 (d1x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|Descent 2 (d2x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|FHeroes Port (Heroes Of Might And Magic 2)
|[http://www.gp32x.com/board/index.php?showtopic=47553 Link]
|Working build
|Pickle
|Strategy
|-
|FreeCiv 2.1.9
|[http://freeciv.wikia.com/wiki/Main_Page Link]
|Working build
|Cpasjuste
|Strategy
|-
|Galactic Artifact
|[http://www.gp32x.com/board/index.php?showtopic=46836 Link]
|Working build
|Trevor Bradley
|Strategy
|-
|Giannas Return
|[http://www.gianas-return.de/ Link]
|Working
|Giannas Team
|Arcade
|-
|Gravity Blocks
|[http://www.gp32x.com/board/index.php?showtopic=47662 Link]
|wip (early in developement)
|Awekening
|Arcade
|-
|Homeworld Port
|[http://www.gp32x.com/board/index.php?showtopic=47565 Link]
|wip
|LinuxHacker
|Simulation
|-
|Human Condition (was TINCS)
|[http://www.gp32x.com/board/index.php?showtopic=46487 Link1][http://www.youtube.com/user/ButtermanHimself Link2]
|wip
|Butterman
|FPP
|-
|Lerp
|[http://grapefruitopia.com/lerp/ Link]
|working build
|benjymous
|2D physics puzzle platformer
|-
|Lord of the Rings Port
|[http://www.gp32x.com/board/index.php?showtopic=46792&hl= Link]
|Unknown
|Daeglin
|RPG
|-
|Mental
|
|Working build, tested on PC
|Colin Jones (xentalion)
|2D Horror Survival Adventure
|-
|Monster!
|[http://christophsdevblog.blogspot.com/ Link]
|wip
|Chris R
|Arcade
|-
|NAEV
|[http://code.google.com/p/naev/ Link]
|wip (waiting for pandora to finish and test)
|bobbens
|Action/RPG/Sim
|-
|Nails Adventure
|[http://www.gp32x.com/board/index.php?showtopic=46961 Link]
|wip
|jsmtux/Mr. Gonzo
|
|-
|OpenLiero (Liero)
|
|working build, need to be polished
|Pickle
|Shoot'Em Up
|-
|OpenTyrian
|[http://code.google.com/p/opentyrian/ Link]
|working build
|Cpasjuste
|Shoot'Em Up
|-
|Pandora Panic!
|[http://www.youtube.com/watch?v=y9d6UXhQP6o Link]
|Working build
|PokeParadox / GP32X Community
|Arcade
|-
|Pandora Pool Panic
|[http://www.gp32x.com/board/index.php?showtopic=46996 Link]
|Almost Finished
|Unfathomable Depths
|Arcade
|-
|PanMMO - Pandora MMO Game via Internet
|[http://www.youtube.com/user/enirya Link]
|wip
|Enirya
|RPG
|-
|Powermanga
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Quake 1
|
|working build
|Pickle
|FPP
|-
|Quake 2
|
|working build
|Pickle
|FPP
|-
|Quake 3
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|FPP
|-
|Quake 3
|
|working build
|Pickle
|FPP
|-
|Reminiscence (flashback)
|[http://cyxdown.free.fr/reminiscence/ Link]
|working build
|Cpasjuste
|Action/Adventure
|-
|Rise of The Triad
|[http://www.gp32x.com/board/index.php?showtopic=47931 Link]
|wip
|arrrgh
|FPP
|-
|Stratagus
|[http://stratagus.sourceforge.net/ Link]
|working build
|Cpasjuste
|RTS Engine
|-
|Super Lumenal
|[http://www.youtube.com/watch?v=sZHi3YT3xuE&feature=channel_page Link]
|wip
|Adventus
|Arcade
|-
|SuperTux 1
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|SuperTux 2
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|Tecnoballz
|[http://mydedibox.fr/_stuff/pandora/ Link]
|Working build
|Cpasjuste
|
|-
|Teeworlds
|[http://www.teeworlds.com/ Link]
|wip
|
|Arcade
|-
|The Mana World
|[http://www.themanaworld.org/ Link]
|Working build
|Cpasjuste
|MMORPG
|-
|uHexen2: Hammer of Thyrion
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Ur-Quan Masters
|[http://www.gp32x.com/board/index.php?showtopic=43625&st=165&p=673047&#entry673047 Link]
|Working build
|
|Space Exploration
|-
|Warioland-inspired game
|[http://www.gp32x.com/board/index.php?/topic/48680-warioland-inspired-game/ Link]
|wip
|foxblock
|Platformer
|-
|We Come In Peace
|[http://www.gp32x.com/board/index.php?showtopic=43655 Link]
|working build
|Otaco
|Strategy
|-
|Where in world is...
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|Casual
|-
|Wizzley Presto and the Mysterious Time Machine
|[http://www.30daygame.com/ Link]
|wip
|Craigix, Zodttd, Ruckage
|Arcade, 30 Day Game Competition
|-
|Wolf4SDL (Wolfenstein 3D)
|
|working build
|Pickle
|FPP
|-
|XSwing Plus
|[http://www.gp32x.com/board/index.php?s=&showtopic=43655&view=findpost&p=733021 Link]
|wip
|Tobse
|Arcade
|-
|ZEQ2Lite
|[http://www.gp32x.com/board/index.php?showtopic=47623&hl= Link]
|Work in progress
|MDave
|Dragonball Z Third Person Fighter/Shooter
|-
|Zdoom
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Zombd
|[http://www.gp32x.com/board/index.php?showtopic=46933 Link]
|Wip
|iprice/Mr Gonzo
|Shoot'Em Up
|}

== Emulators ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Emulated System
! Link
! Status
! Author/Port Author
! Notes
|-
|Caprice32
|Amstrad CPC
|[http://www.gp32x.com/board/index.php?showtopic=48140 Link1] [http://www.caprice32.cybercube.com/ Link2]
|wip
|hdonk
|
|-
|DosBox
|x86 DOS
|
|working build
|Pickle
|
|-
|FinalBurnAdvance
|CPS1/2/3/taito...
|[http://www.youtube.com/watch?v=06hjDLMBaf8 Link]
|
|Squidge
|
|-
|Frotz
|Z-Machine interpreter
|[http://www.cosam.org/computers/pandora/frotz-2.43.zip Link]
|working build
|SteveM
|
|-
|Fuse
|ZX Spectrum
|[http://www.cosam.org/computers/pandora/fuse-0.9.0.zip Link]
|working build
|SteveM
|
|-
|GnGeo
|SNK NeoGeo
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|gpSP
|Nintendo GBA
|
|wip
|ZodTTD
|
|-
|Hatari
|Atari ST
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|Jzintv
|Mattel Intellivision
|[http://www.gp32x.com/board/index.php?showtopic=48035 Link]
|
|WizardStan
|
|-
|MAME4All
|Arcade
|[http://www.youtube.com/user/franxism Link]
|
|Franxis
|
|-
|Mupen64plus
|Nintendo 64
|[http://www.gp32x.com/board/index.php?/topic/49358-mupen64plus/ Link]
|working build
|Ari64
|Adventus ported graphics plugin
|-
|NeoPop
|SNK NeoGeo Pocket
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|NullDC
|Sega Dreamcast
|[http://www.gp32x.com/board/index.php?s=&showtopic=47065&view=findpost&p=709910 Link]
|Wip
|Zezu / drkIIraziel
|
|-
|PandaSNES
|Nintendo SNES
|[http://www.gp32x.com/board/index.php?showtopic=43213 Link]
|wip
|Squidge
|
|-
|Pandora-PSP
|Sony Playstation Portable
|[http://jayfoxrox.bplaced.net/pandora-psp/ Link]
|wip
|[[User:JayFoxRox|JayFoxRox]]
|
|-
|PAtari
|Atari 800
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PicoDrive
|Sega Genesis/CD/32x
|[http://www.youtube.com/watch?v=QDbLQI91510 Link]
|working build
|Notaz
|Fullspeed emulator
|-
|PSMS
|Sega Master System
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PSnes
|Nintendo SNES
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Psx4All
|Sony PlayStation
|[http://www.zodttd.com Link]
|Not Status, working build
|ZodTTD
|
|-
|ScummVM
|x86 Scumm engine games
|
|Working build
|DJ Willis
|Fullspeed emulator
|-
|SIMH
|old hardware
|[http://www.cosam.org/computers/pandora/simh-3.8.zip Link]
|working build
|SteveM
|
|-
|Temper
|NEC PC Engine
|[http://exophase.devzero.co.uk/ Link]
|wip
|Exophase
|Fullspeed emulator
|-
|Tempest
|Atari Jaguar
|[http://www.gp32x.com/board/index.php?showtopic=43119 Link]
|
|Firefox
|
|-
|Uae4All
|Amiga
|[http://www.gp32x.com/board/index.php?showtopic=44100 Link]
|Working build
|
|
|-
|XMAME
|Arcade
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|}

== Graphic Engines ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|GemRB (Infinity Engine)
|
|wip
|Adventus
|open-source implementation of Bioware's Infinity Engine, supports games including Baldurs Gate 2 and Planescape Torment.
|-
|GLES2D
|
|Wip
|Cpasjuste
|OpenGL ES 2D library
|-
|GL-WES-v2.0
|[http://code.google.com/p/gl-wes-v2/ link]
|Working Build
|Adventus
|Opensource OpenGL 2.0 driver built on OpenGL ES 2.0.
|-
|Irrlicht
|[http://irrlicht.sourceforge.net/] [http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=32538&start=45]
|working build
|Hybrid
|3D game engine
|-
|NSS Engine
|[http://www.nosiestastudios.com/wiki/ Link1] [http://www.youtube.com/user/Prompt84 Link2]
|
|No Siesta Studios
|
|-
|OGRE Engine
|[http://www.gp32x.com/board/index.php?showtopic=46706 Link1] [http://www.youtube.com/watch?v=LDtUE5PIhV0 Link2]
|
|
|3D real-time renderer
|-
|Otaco Glost Engine
|[http://www.youtube.com/user/otacogloost Link1], [http://www.gp32x.com/board/index.php?/topic/48393-i-did-stuff/page__p__736650&#entry736650 Link2]
|working
|Otaco
|
|-
|Quad-Ren 2D
|[http://quad-ren.sourceforge.net/index.php Link]
|
|Hessiess
|
|-
|SDL GLES
|[http://github.com/Cpasjuste/sdl-1.2.13_gles/tree Link]
|working
|Cpasjuste
|
|-
|XreaL
|[http://xreal.sourceforge.net/xrealwiki/ Link]
|
|Pickle [?]
|
|}

== Other programs ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|AbiWord - Word Processor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Claws Mail
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Epiphany Web Bowser
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|FireFox - Internet Browser
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GIMP - Image Editor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GMenu
|[http://www.youtube.com/watch?v=VYzi8gziC7E Link]
|Working build
|Pandora Team
|
|-
|Gnumeric Spreadsheet - Spreadsheet
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GoView
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Image Gallery
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Inside The Box
|[http://www.openpandora.pl Link1] [http://www.youtube.com/watch?v=uLMmJBDEs2E Link2]
|wip
|StreaK
|Pandora e-zine
|-
|IRC Client
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|LeafPad
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Matchbox Shell / GUI
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|MPlayer
|[http://www.gp32x.com/board/index.php?showtopic=41420 Link1] [http://www.youtube.com/watch?v=v9RAPNa-55k Link2]
|Working build
|Squidge
|
|-
|Math-NEON
|[http://code.google.com/p/math-neon/ Link1]
|Wip
|Adventus
|cmath like library optimised for ARM NEON coprocessor.
|-
|Pandaphone
|[http://www.gp32x.com/board/index.php?/topic/48327-pandaphone/ Link]
|
|jb0yx
|A project to incorporate the Open Pandora handheld device with cell phone technology
|-
|Pandora Sync Suite
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|for Windows 9x/NT
|-
|Pangea GUI
|[http://www.gp32x.com/board/index.php?showtopic=45631&hl=pangea Link]
|WIP
|efegea
|Gmenu alternative
|-
|PDM
|[http://github.com/Cpasjuste/pdm/tree Link]
|
|Cpasjuste
|Light desktop manager for Pandora
|-
|PGui
|[http://github.com/Cpasjuste/pgui/tree Link]
|
|Cpasjuste
|Standard emulator fronted for Pandora
|-
|Pidgin - IM (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|PMenu
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|Minimal Menu for Pandora
|-
|PND Maker (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Qemu
|[http://www.nongnu.org/qemu/status.html Link]
|testing build
|Fabrice Bellard
|open source machine emulator and virtualizer
|-
|Scale
|[http://www.youtube.com/user/Zoxc64 Link]
|wip
|Zoxc64
|Minimal Menu for Pandora
|-
|Simple Dev Studio for Pandora
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|for Windows 9x/NT
|-
|[[TINXL]]
|[[TINXL]]
|
|
|Application stack for multiplayer internet games
|-
|[[TS2A]]
|[[TS2A]]
|Documentation only
||[[User:JayFoxRox|JayFoxRox]]
|Teamspeak 2 Alternative Client / Server, Needs developer
|-
|XMMS
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|ZiB Emulator Frontend
|[http://www.gp32x.com/board/index.php?showtopic=47203 Link1] [http://www.youtube.com/watch?v=UJvON8lCM3M Link2]
|
|Aimless_E
|
|}

== Demos / Technical Demos for OpenPandora ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|OpenGL Cell Shading
|[http://www.youtube.com/watch?v=cpAj0jHglGw Link]
|working build
|
|
|-
|OpenGL Demo with MP3 Playback
|[http://www.youtube.com/watch?v=hkx18kruRJs Link]
|working build
|
|
|-
|OpenGL Skull Demo
|[http://www.youtube.com/watch?v=qG7EDaZpyOo Link]
|working build
|
|
|-
|WaveDemo
|[http://www.youtube.com/watch?v=4wgEHFCq9Lo Link]
|Working
|Otaco
|
|}

Software projects

2009-10-22T06:43:33Z

Adventus: /* Other programs */

See the [[Port Requests]] article for open-source projects which ''could'' be ported but have not been taken on by anyone yet.

== Operating Systems ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Android Omap
|[http://elinux.org/Android_on_OMAP Link]
|wip
|
|
|-
|Angstrom Linux
|[http://www.angstrom-distribution.org/ Link]
|Working build, not completed
|
|
|-
|AROS Arm
|[http://projects.powerdeveloper.org/project/imx515/735 Link]
|wip
|
|
|-
|FreeBSD
|[http://wiki.freebsd.org/FreeBSD/arm/OMAP Link]
|wip
|
|
|-
|Gentoo Linux
|[http://gentoo.openpandora.org Link]
|Working build, not completed
|javaJake, Viridior
|IRC: (FreeNode) #gentoo-pandora
|-
|HaikuOS
|[http://www.haiku-os.org Link]
|wip
|
|
|-
|Ubuntu ARM
|[http://www.ubuntu.com/products/whatisubuntu/arm Link]
|wip
|
|
|-
|Fedora ARM
|
|Unknown
|
|
|}

== Games ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Abuse
|[http://abuse.zoy.org/ Link]
|working build
|Cpasjuste
|2D Platform
|-
|Battle for Wesnoth v1.6.2
|[http://www.gp32x.com/board/index.php?showtopic=47936 Link]
|working build
|Cpasjuste
|Strategy
|-
|BattleJewels
|
|Completed build for GP2X, WIP for Pandora
|Skeezix
|Logical
|-
|BlobWars
|[http://www.parallelrealities.co.uk/projects/blobWars.php Link]
|working build
|Cpasjuste
|2D Platform
|-
|Caster
|[http://www.gp32x.com/board/index.php?showtopic=46813 Link]
|Working build (tested on PC)
|Svartalf
|RPG
|-
|Chaotic Vortex
|[http://www.gp32x.com/board/index.php?/topic/49754-chaotic-vortex-dual-stick-arena-shooter Link]
|WIP
|Ruben
|Dual stick 2D shooter
|-
|Descent 1 (d1x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|Descent 2 (d2x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|FHeroes Port (Heroes Of Might And Magic 2)
|[http://www.gp32x.com/board/index.php?showtopic=47553 Link]
|Working build
|Pickle
|Strategy
|-
|FreeCiv 2.1.9
|[http://freeciv.wikia.com/wiki/Main_Page Link]
|Working build
|Cpasjuste
|Strategy
|-
|Galactic Artifact
|[http://www.gp32x.com/board/index.php?showtopic=46836 Link]
|Working build
|Trevor Bradley
|Strategy
|-
|Giannas Return
|[http://www.gianas-return.de/ Link]
|Working
|Giannas Team
|Arcade
|-
|Gravity Blocks
|[http://www.gp32x.com/board/index.php?showtopic=47662 Link]
|wip (early in developement)
|Awekening
|Arcade
|-
|Homeworld Port
|[http://www.gp32x.com/board/index.php?showtopic=47565 Link]
|wip
|LinuxHacker
|Simulation
|-
|Human Condition (was TINCS)
|[http://www.gp32x.com/board/index.php?showtopic=46487 Link1][http://www.youtube.com/user/ButtermanHimself Link2]
|wip
|Butterman
|FPP
|-
|Lerp
|[http://grapefruitopia.com/lerp/ Link]
|working build
|benjymous
|2D physics puzzle platformer
|-
|Lord of the Rings Port
|[http://www.gp32x.com/board/index.php?showtopic=46792&hl= Link]
|Unknown
|Daeglin
|RPG
|-
|Mental
|
|Working build, tested on PC
|Colin Jones (xentalion)
|2D Horror Survival Adventure
|-
|Monster!
|[http://christophsdevblog.blogspot.com/ Link]
|wip
|Chris R
|Arcade
|-
|NAEV
|[http://code.google.com/p/naev/ Link]
|wip (waiting for pandora to finish and test)
|bobbens
|Action/RPG/Sim
|-
|Nails Adventure
|[http://www.gp32x.com/board/index.php?showtopic=46961 Link]
|wip
|jsmtux/Mr. Gonzo
|
|-
|OpenLiero (Liero)
|
|working build, need to be polished
|Pickle
|Shoot'Em Up
|-
|OpenTyrian
|[http://code.google.com/p/opentyrian/ Link]
|working build
|Cpasjuste
|Shoot'Em Up
|-
|Pandora Panic!
|[http://www.youtube.com/watch?v=y9d6UXhQP6o Link]
|Working build
|PokeParadox / GP32X Community
|Arcade
|-
|Pandora Pool Panic
|[http://www.gp32x.com/board/index.php?showtopic=46996 Link]
|Almost Finished
|Unfathomable Depths
|Arcade
|-
|PanMMO - Pandora MMO Game via Internet
|[http://www.youtube.com/user/enirya Link]
|wip
|Enirya
|RPG
|-
|Powermanga
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Quake 1
|
|working build
|Pickle
|FPP
|-
|Quake 2
|
|working build
|Pickle
|FPP
|-
|Quake 3
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|FPP
|-
|Quake 3
|
|working build
|Pickle
|FPP
|-
|Reminiscence (flashback)
|[http://cyxdown.free.fr/reminiscence/ Link]
|working build
|Cpasjuste
|Action/Adventure
|-
|Rise of The Triad
|[http://www.gp32x.com/board/index.php?showtopic=47931 Link]
|wip
|arrrgh
|FPP
|-
|Stratagus
|[http://stratagus.sourceforge.net/ Link]
|working build
|Cpasjuste
|RTS Engine
|-
|Super Lumenal
|[http://www.youtube.com/watch?v=sZHi3YT3xuE&feature=channel_page Link]
|wip
|Adventus
|Arcade
|-
|SuperTux 1
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|SuperTux 2
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|Tecnoballz
|[http://mydedibox.fr/_stuff/pandora/ Link]
|Working build
|Cpasjuste
|
|-
|Teeworlds
|[http://www.teeworlds.com/ Link]
|wip
|
|Arcade
|-
|The Mana World
|[http://www.themanaworld.org/ Link]
|Working build
|Cpasjuste
|MMORPG
|-
|uHexen2: Hammer of Thyrion
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Ur-Quan Masters
|[http://www.gp32x.com/board/index.php?showtopic=43625&st=165&p=673047&#entry673047 Link]
|Working build
|
|Space Exploration
|-
|Warioland-inspired game
|[http://www.gp32x.com/board/index.php?/topic/48680-warioland-inspired-game/ Link]
|wip
|foxblock
|Platformer
|-
|We Come In Peace
|[http://www.gp32x.com/board/index.php?showtopic=43655 Link]
|working build
|Otaco
|Strategy
|-
|Where in world is...
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|Casual
|-
|Wizzley Presto and the Mysterious Time Machine
|[http://www.30daygame.com/ Link]
|wip
|Craigix, Zodttd, Ruckage
|Arcade, 30 Day Game Competition
|-
|Wolf4SDL (Wolfenstein 3D)
|
|working build
|Pickle
|FPP
|-
|XSwing Plus
|[http://www.gp32x.com/board/index.php?s=&showtopic=43655&view=findpost&p=733021 Link]
|wip
|Tobse
|Arcade
|-
|ZEQ2Lite
|[http://www.gp32x.com/board/index.php?showtopic=47623&hl= Link]
|Work in progress
|MDave
|Dragonball Z Third Person Fighter/Shooter
|-
|Zdoom
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Zombd
|[http://www.gp32x.com/board/index.php?showtopic=46933 Link]
|Wip
|iprice/Mr Gonzo
|Shoot'Em Up
|}

== Emulators ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Emulated System
! Link
! Status
! Author/Port Author
! Notes
|-
|Caprice32
|Amstrad CPC
|[http://www.gp32x.com/board/index.php?showtopic=48140 Link1] [http://www.caprice32.cybercube.com/ Link2]
|wip
|hdonk
|
|-
|DosBox
|x86 DOS
|
|working build
|Pickle
|
|-
|FinalBurnAdvance
|CPS1/2/3/taito...
|[http://www.youtube.com/watch?v=06hjDLMBaf8 Link]
|
|Squidge
|
|-
|Frotz
|Z-Machine interpreter
|[http://www.cosam.org/computers/pandora/frotz-2.43.zip Link]
|working build
|SteveM
|
|-
|Fuse
|ZX Spectrum
|[http://www.cosam.org/computers/pandora/fuse-0.9.0.zip Link]
|working build
|SteveM
|
|-
|GnGeo
|SNK NeoGeo
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|gpSP
|Nintendo GBA
|
|wip
|ZodTTD
|
|-
|Hatari
|Atari ST
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|Jzintv
|Mattel Intellivision
|[http://www.gp32x.com/board/index.php?showtopic=48035 Link]
|
|WizardStan
|
|-
|MAME4All
|Arcade
|[http://www.youtube.com/user/franxism Link]
|
|Franxis
|
|-
|Mupen64plus
|Nintendo 64
|[http://www.gp32x.com/board/index.php?/topic/49358-mupen64plus/ Link]
|working build
|Ari64
|Pickle working on OpenGL
|-
|NeoPop
|SNK NeoGeo Pocket
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|NullDC
|Sega Dreamcast
|[http://www.gp32x.com/board/index.php?s=&showtopic=47065&view=findpost&p=709910 Link]
|Wip
|Zezu / drkIIraziel
|
|-
|PandaSNES
|Nintendo SNES
|[http://www.gp32x.com/board/index.php?showtopic=43213 Link]
|wip
|Squidge
|
|-
|Pandora-PSP
|Sony Playstation Portable
|[http://jayfoxrox.bplaced.net/pandora-psp/ Link]
|wip
|[[User:JayFoxRox|JayFoxRox]]
|
|-
|PAtari
|Atari 800
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PicoDrive
|Sega Genesis/CD/32x
|[http://www.youtube.com/watch?v=QDbLQI91510 Link]
|working build
|Notaz
|Fullspeed emulator
|-
|PSMS
|Sega Master System
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PSnes
|Nintendo SNES
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Psx4All
|Sony PlayStation
|[http://www.zodttd.com Link]
|Not Status, working build
|ZodTTD
|
|-
|ScummVM
|x86 Scumm engine games
|
|Working build
|DJ Willis
|Fullspeed emulator
|-
|SIMH
|old hardware
|[http://www.cosam.org/computers/pandora/simh-3.8.zip Link]
|working build
|SteveM
|
|-
|Temper
|NEC PC Engine
|[http://exophase.devzero.co.uk/ Link]
|wip
|Exophase
|Fullspeed emulator
|-
|Tempest
|Atari Jaguar
|[http://www.gp32x.com/board/index.php?showtopic=43119 Link]
|
|Firefox
|
|-
|Uae4All
|Amiga
|[http://www.gp32x.com/board/index.php?showtopic=44100 Link]
|Working build
|
|
|-
|XMAME
|Arcade
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|}

== Graphic Engines ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|GemRB (Infinity Engine)
|
|wip
|Adventus
|open-source implementation of Bioware's Infinity Engine, supports games including Baldurs Gate 2 and Planescape Torment.
|-
|GLES2D
|
|Wip
|Cpasjuste
|OpenGL ES 2D library
|-
|GL-WES-v2.0
|[http://code.google.com/p/gl-wes-v2/ link]
|Working Build
|Adventus
|Opensource OpenGL 2.0 driver built on OpenGL ES 2.0.
|-
|Irrlicht
|[http://irrlicht.sourceforge.net/] [http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=32538&start=45]
|working build
|Hybrid
|3D game engine
|-
|NSS Engine
|[http://www.nosiestastudios.com/wiki/ Link1] [http://www.youtube.com/user/Prompt84 Link2]
|
|No Siesta Studios
|
|-
|OGRE Engine
|[http://www.gp32x.com/board/index.php?showtopic=46706 Link1] [http://www.youtube.com/watch?v=LDtUE5PIhV0 Link2]
|
|
|3D real-time renderer
|-
|Otaco Glost Engine
|[http://www.youtube.com/user/otacogloost Link1], [http://www.gp32x.com/board/index.php?/topic/48393-i-did-stuff/page__p__736650&#entry736650 Link2]
|working
|Otaco
|
|-
|Quad-Ren 2D
|[http://quad-ren.sourceforge.net/index.php Link]
|
|Hessiess
|
|-
|SDL GLES
|[http://github.com/Cpasjuste/sdl-1.2.13_gles/tree Link]
|working
|Cpasjuste
|
|-
|XreaL
|[http://xreal.sourceforge.net/xrealwiki/ Link]
|
|Pickle [?]
|
|}

== Other programs ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|AbiWord - Word Processor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Claws Mail
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Epiphany Web Bowser
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|FireFox - Internet Browser
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GIMP - Image Editor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GMenu
|[http://www.youtube.com/watch?v=VYzi8gziC7E Link]
|Working build
|Pandora Team
|
|-
|Gnumeric Spreadsheet - Spreadsheet
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GoView
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Image Gallery
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Inside The Box
|[http://www.openpandora.pl Link1] [http://www.youtube.com/watch?v=uLMmJBDEs2E Link2]
|wip
|StreaK
|Pandora e-zine
|-
|IRC Client
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|LeafPad
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Matchbox Shell / GUI
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|MPlayer
|[http://www.gp32x.com/board/index.php?showtopic=41420 Link1] [http://www.youtube.com/watch?v=v9RAPNa-55k Link2]
|Working build
|Squidge
|
|-
|Math-NEON
|[http://code.google.com/p/math-neon/ Link1]
|Wip
|Adventus
|cmath like library optimised for ARM NEON coprocessor.
|-
|Pandaphone
|[http://www.gp32x.com/board/index.php?/topic/48327-pandaphone/ Link]
|
|jb0yx
|A project to incorporate the Open Pandora handheld device with cell phone technology
|-
|Pandora Sync Suite
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|for Windows 9x/NT
|-
|Pangea GUI
|[http://www.gp32x.com/board/index.php?showtopic=45631&hl=pangea Link]
|WIP
|efegea
|Gmenu alternative
|-
|PDM
|[http://github.com/Cpasjuste/pdm/tree Link]
|
|Cpasjuste
|Light desktop manager for Pandora
|-
|PGui
|[http://github.com/Cpasjuste/pgui/tree Link]
|
|Cpasjuste
|Standard emulator fronted for Pandora
|-
|Pidgin - IM (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|PMenu
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|Minimal Menu for Pandora
|-
|PND Maker (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Qemu
|[http://www.nongnu.org/qemu/status.html Link]
|testing build
|Fabrice Bellard
|open source machine emulator and virtualizer
|-
|Scale
|[http://www.youtube.com/user/Zoxc64 Link]
|wip
|Zoxc64
|Minimal Menu for Pandora
|-
|Simple Dev Studio for Pandora
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|for Windows 9x/NT
|-
|[[TINXL]]
|[[TINXL]]
|
|
|Application stack for multiplayer internet games
|-
|[[TS2A]]
|[[TS2A]]
|Documentation only
||[[User:JayFoxRox|JayFoxRox]]
|Teamspeak 2 Alternative Client / Server, Needs developer
|-
|XMMS
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|ZiB Emulator Frontend
|[http://www.gp32x.com/board/index.php?showtopic=47203 Link1] [http://www.youtube.com/watch?v=UJvON8lCM3M Link2]
|
|Aimless_E
|
|}

== Demos / Technical Demos for OpenPandora ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|OpenGL Cell Shading
|[http://www.youtube.com/watch?v=cpAj0jHglGw Link]
|working build
|
|
|-
|OpenGL Demo with MP3 Playback
|[http://www.youtube.com/watch?v=hkx18kruRJs Link]
|working build
|
|
|-
|OpenGL Skull Demo
|[http://www.youtube.com/watch?v=qG7EDaZpyOo Link]
|working build
|
|
|-
|WaveDemo
|[http://www.youtube.com/watch?v=4wgEHFCq9Lo Link]
|Working
|Otaco
|
|}

Floating Point Optimization

2009-08-01T01:06:56Z

Adventus: /* Summary */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* Subnormal numbers are being flushed to zero
* Default NaN mode is active
* No floating point exceptions are enabled

I'm not sure if Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require slower double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt, etc). By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC (except the CSL 2009q1 release) supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP to ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

The last common source of transfers is when you cast a floating point value as an integer, by default all integer work will be done in the ARM pipeline and hence a transfer operation occurs. This is particularly problematic for complex algorithms that rely on bitwise or rounding operations on floating point numbers, ie almost all the functions in cmath depend on range reduction (rounding). A smart compiler would recognize that they can almost always be done in the NEON's integer pipeline.

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
It's often said amongst software developers that you 'may aswell not bother trying to out perform a compiler', whilst there is a grain of truth in this where X86 is concerned, this is definitely not the case with Floating point on the ARM Cortex A8. Infact it is almost the opposite, you can almost always make significant gains via targeting the NEON. Therefore, Inorder to achieve the best floating point performance on the Pandora (or ARM Cortex A8 device):
* Use the CodeSourcery 2007q3 or 2009q1 releases and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Use NEON intrinsics / ASM when ever you find a bottlenecking FP function. You can do better than the compiler.
* Minimize Conditional Branches
* Enable RunFast mode

For softfp:
* Inline floating point code (unless its very large)
* Pass FP arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:58:13Z

Adventus: /* NFP / VFP to ARM Transfers */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* Subnormal numbers are being flushed to zero
* Default NaN mode is active
* No floating point exceptions are enabled

I'm not sure if Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require slower double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt, etc). By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC (except the CSL 2009q1 release) supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP to ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

The last common source of transfers is when you cast a floating point value as an integer, by default all integer work will be done in the ARM pipeline and hence a transfer operation occurs. This is particularly problematic for complex algorithms that rely on bitwise or rounding operations on floating point numbers, ie almost all the functions in cmath depend on range reduction (rounding). A smart compiler would recognize that they can almost always be done in the NEON's integer pipeline.

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:47:36Z

Adventus: /* NFP / VFP to ARM Transfers */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* Subnormal numbers are being flushed to zero
* Default NaN mode is active
* No floating point exceptions are enabled

I'm not sure if Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require slower double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt, etc). By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC (except the CSL 2009q1 release) supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP to ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:46:51Z

Adventus: /* NFP / VFP to ARM Transfers */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* Subnormal numbers are being flushed to zero
* Default NaN mode is active
* No floating point exceptions are enabled

I'm not sure if Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require slower double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt, etc). By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC (except the CSL 2009q1 release) supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:45:58Z

Adventus: /* Single Precision Floating Point */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* Subnormal numbers are being flushed to zero
* Default NaN mode is active
* No floating point exceptions are enabled

I'm not sure if Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require slower double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt, etc). By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:44:32Z

Adventus: /* VFP-Lite RunFast */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* Subnormal numbers are being flushed to zero
* Default NaN mode is active
* No floating point exceptions are enabled

I'm not sure if Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:43:38Z

Adventus: /* VFP-Lite RunFast */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* Subnormal numbers are being flushed to zero
* Default NaN mode is active
* No floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution packaged with the Pandora. If it isn't you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:42:29Z

Adventus: /* VFP-Lite RunFast */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* Subnormal numbers are being flushed to zero
* Default NaN mode is active
* No floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:41:16Z

Adventus: /* Compiler Support */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:39:47Z

Adventus: /* Compiler Support */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet. One big problem with the current compilers is the heavy dependence on VFP code, currently they only output NEON code when an obvious chance of vectorization is encountered (rarely). Apart from the esoteric rounding, vector, etc modes of the VFP (most of which compilers don't use) and predication (used occasionally), most VFP floating point instructions can be exactly replicated using an order of magnitude faster NEON instructions.... Infact it has been reported to me that the GCC packaged with the iPhone 3GS SDK does exactly this. Hopefully future compilers will support this feature.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / CSL 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:24:28Z

Adventus: /* Compiler Support */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / CSL 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa, so make sure your libraries have the correct ABI. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-08-01T00:22:36Z

Adventus: /* Compiler Support */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the Code Sourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Code Sourcery Compiler versions:
* CSL 2007q3: Working NEON, Softfp Support
* CSL 2008q3: Broken NEON!
* CSL 2009q1: Working NEON, Hardfp + Softfp Support

Generally the CS2007q3 release is recommended, the CSL 2009q1 release is promising but it has not been thoroughly tested yet.

Inorder to instruct the compiler to produce NEON or VFP code you should use the following compile flags: -mfpu=neon or -mfpu=vfp. Unfortunately the CSL 2007 / CSL 2008 toolchains do not support the passing of values in floating point registers (i talk about this some more in the Transfers section), so you must specify a software ABI via -mfloat-abi=softfp. The CSL 2009q1 release is the first release to support the passing of values in FP registers (AKA hardfp) via the -mfloat-abi=hard compile flag. Note that hardfp compiled binaries are not compatible with softfp ones and vice versa. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=(softfp|hard) -ffast-math -fsingle-precision-constant''' where -mfloat-abi=hard for the CSL 2009q1 release and softfp for all the others.

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-07-31T23:59:23Z

Adventus: /* Introduction */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precision arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking between 18 - 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the CodeSourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Compiler versions:
* CS2007q3: Working NEON
* CS2008q3: Broken NEON
* CS2009q1: Working NEON (Apparently)

Generally the CS2007q3 release is recommended. The newest release does have better support for vectorizing integer and floating point computations on the NEON, but it has not been thoroughly tested yet.

Inorder to instruct the compiler to produce NEON / VFP code you should use the following compile flags: -mfpu=neon -mfloat-abi=softfp, or -mfpu=vfp -mfloat-abi=softfp. Unfortunately the prebuilt toolchains do not support the passing / returning of values in floating point registers (i talk about this some more in the Transfers section), there is however a patch being tested that supports hardfp and may be included in future toolchains. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant'''

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-07-26T02:42:28Z

Adventus: /* VFP-Lite RunFast */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precession arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking from 18 to 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the CodeSourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Compiler versions:
* CS2007q3: Working NEON
* CS2008q3: Broken NEON
* CS2009q1: Working NEON (Apparently)

Generally the CS2007q3 release is recommended. The newest release does have better support for vectorizing integer and floating point computations on the NEON, but it has not been thoroughly tested yet.

Inorder to instruct the compiler to produce NEON / VFP code you should use the following compile flags: -mfpu=neon -mfloat-abi=softfp, or -mfpu=vfp -mfloat-abi=softfp. Unfortunately the prebuilt toolchains do not support the passing / returning of values in floating point registers (i talk about this some more in the Transfers section), there is however a patch being tested that supports hardfp and may be included in future toolchains. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant'''

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instructions to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-07-26T02:39:24Z

Adventus: /* Introduction */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precession arithmetic, as well as properly handling exceptions and subnormal numbers. However, Due to the full spec compliance and presence of the NEON, it is a relatively slow implementation in the A8, usually taking from 18 to 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the CodeSourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Compiler versions:
* CS2007q3: Working NEON
* CS2008q3: Broken NEON
* CS2009q1: Working NEON (Apparently)

Generally the CS2007q3 release is recommended. The newest release does have better support for vectorizing integer and floating point computations on the NEON, but it has not been thoroughly tested yet.

Inorder to instruct the compiler to produce NEON / VFP code you should use the following compile flags: -mfpu=neon -mfloat-abi=softfp, or -mfpu=vfp -mfloat-abi=softfp. Unfortunately the prebuilt toolchains do not support the passing / returning of values in floating point registers (i talk about this some more in the Transfers section), there is however a patch being tested that supports hardfp and may be included in future toolchains. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant'''

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instruction to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-07-26T02:11:52Z

Adventus:

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precession arithmetic, as well as properly handling exceptions and subnormal numbers. However, This full spec compliance and due to the presence of the NEON has resulted in a relatively slow implementation, it usually takes from 18 to 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the CodeSourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Compiler versions:
* CS2007q3: Working NEON
* CS2008q3: Broken NEON
* CS2009q1: Working NEON (Apparently)

Generally the CS2007q3 release is recommended. The newest release does have better support for vectorizing integer and floating point computations on the NEON, but it has not been thoroughly tested yet.

Inorder to instruct the compiler to produce NEON / VFP code you should use the following compile flags: -mfpu=neon -mfloat-abi=softfp, or -mfpu=vfp -mfloat-abi=softfp. Unfortunately the prebuilt toolchains do not support the passing / returning of values in floating point registers (i talk about this some more in the Transfers section), there is however a patch being tested that supports hardfp and may be included in future toolchains. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant'''

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instruction to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Floating Point ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

Another thing to watch out for is the double versions of the functions in libm (sin, exp, sqrt) etc. By default these functions operate on double precision floating point values and suffer the same problems as the constants. Luckily libm supplies floating point versions aswell, they can be accessed by appending an 'f' to the end of the function. ie sinf(), expf(), sqrtf().

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-07-26T02:04:14Z

Adventus: /* Compiler Support */

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precession arithmetic, as well as properly handling exceptions and subnormal numbers. However, This full spec compliance and due to the presence of the NEON has resulted in a relatively slow implementation, it usually takes from 18 to 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the CodeSourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Compiler versions:
* CS2007q3: Working NEON
* CS2008q3: Broken NEON
* CS2009q1: Working NEON (Apparently)

Generally the CS2007q3 release is recommended. The newest release does have better support for vectorizing integer and floating point computations on the NEON, but it has not been thoroughly tested yet.

Inorder to instruct the compiler to produce NEON / VFP code you should use the following compile flags: -mfpu=neon -mfloat-abi=softfp, or -mfpu=vfp -mfloat-abi=softfp. Unfortunately the prebuilt toolchains do not support the passing / returning of values in floating point registers (i talk about this some more in the Transfers section), there is however a patch being tested that supports hardfp and may be included in future toolchains. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant'''

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instruction to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Constants ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-07-26T01:06:54Z

Adventus:

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precession arithmetic, as well as properly handling exceptions and subnormal numbers. However, This full spec compliance and due to the presence of the NEON has resulted in a relatively slow implementation, it usually takes from 18 to 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the CodeSourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Compiler versions:
* CS2007q3: Working NEON
* CS2008q1: Broken NEON
* CS2009q1: Partially Working NEON.

Generally the CS2007q3 release is recommended. The newest release does have better support for vectorizing integer and floating point computations on the NEON, but this has proven to be buggy.

Inorder to instruct the compiler to produce NEON / VFP code you should use the following compile flags: -mfpu=neon -mfloat-abi=softfp, or -mfpu=vfp -mfloat-abi=softfp. Unfortunately the prebuilt toolchains do not support the passing / returning of values in floating point registers (i talk about this some more in the Transfers section), there is however a patch being tested that supports hardfp and may be included in future toolchains. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant'''

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instruction to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Constants ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Use NEON intrinsics / ASM for vector, or even scalar, code.
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.

Floating Point Optimization

2009-07-26T01:04:39Z

Adventus:

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precession arithmetic, as well as properly handling exceptions and subnormal numbers. However, This full spec compliance and due to the presence of the NEON has resulted in a relatively slow implementation, it usually takes from 18 to 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the CodeSourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Compiler versions:
* CS2007q3: Working NEON
* CS2008q1: Broken NEON
* CS2009q1: Partially Working NEON.

Generally the CS2007q3 release is recommended. The newest release does have better support for vectorizing integer and floating point computations on the NEON, but this has proven to be buggy.

Inorder to instruct the compiler to produce NEON / VFP code you should use the following compile flags: -mfpu=neon -mfloat-abi=softfp, or -mfpu=vfp -mfloat-abi=softfp. Unfortunately the prebuilt toolchains do not support the passing / returning of values in floating point registers (i talk about this some more in the Transfers section), there is however a patch being tested that supports hardfp and may be included in future toolchains. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant'''

== VFP-Lite RunFast ==
Under the correct circumstances some of The VFPs instructions will be executed in the NEON coprocessor. Unfortunately this does not gain the full benefit of the NEON, it still takes 7 cycles for an FMAC / FMUL / FADD. Due to this quirk you will likely get better scalar performance by accessing the NEON directly via Intrinsics or ASM.

Inorder for VFP instruction to execute in the NFP the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Constants ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.
* Use NEON intrinsics / ASM for vectoriseable code.

Floating Point Optimization

2009-07-26T00:41:56Z

Adventus:

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precession arithmetic, as well as properly handling exceptions and subnormal numbers. However, This full spec compliance and due to the presence of the NEON has resulted in a relatively slow implementation, it usually takes from 18 to 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the CodeSourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Compiler versions:
* CS2007q3: Working NEON
* CS2008q1: Broken NEON
* CS2009q1: Partially Working NEON.

Generally the CS2007q3 release is recommended. The newest release does have better support for vectorizing integer and floating point computations on the NEON, but this has proven to be buggy.

Inorder to instruct the compiler to produce NEON / VFP code you should use the following compile flags: -mfpu=neon -mfloat-abi=softfp, or -mfpu=vfp -mfloat-abi=softfp. Unfortunately the prebuilt toolchains do not support the passing / returning of values in floating point registers (i talk about this some more in the Transfers section), there is however a patch being tested that supports hardfp and may be included in future toolchains. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: '''-O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant'''

== VFP-Lite RunFast ==
The VFP-Lite has one saving grace, under the correct circumstances some of its instructions will be executed in the NEON coprocessor and will gain benefits of doing so. Inorder for this to occur the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Constants ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Use the CodeSourcery 2007q3 release and these flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant
* Only use single precision floating point
* Enable RunFast mode
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.
* Use NEON intrinsics / ASM for vectoriseable code.

Floating Point Optimization

2009-07-26T00:39:43Z

Adventus:

== Introduction ==
In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very tricky to write) or very slow software floating point emulation. Fortunately the ARM Cortex A8 found in the OMAP3 has 2 Floating Point Units, a non-pipelined VFP-lite conforming to the IEEE754 standard for floating point arithmetic and a pipelined SIMD NEON coprocessor. The VFP-lite can handle both single and double precession arithmetic, as well as properly handling exceptions and subnormal numbers. However, This full spec compliance and due to the presence of the NEON has resulted in a relatively slow implementation, it usually takes from 18 to 21 cycles to perform a single precision multiply accumulate. The NEON unit on the other hand is designed for very fast single precision vector math, it can sustain multiply accumulates at a rate of two per cycle. Efficiently utilizing these coprocessors in GCC will be the focus of this article.

'''Note:''' In this article I refer to the A8's integer pipeline as the "ARM" , the VFP-lite as simply the "VFP" and the NEON unit as the "NFP".

== Compiler Support ==
The NEON + VFP-lite is a new design from ARM and hence does not yet have very mature compiler support. At present the CodeSourcery toolchain has the best support since the mainline GCCs do not support NEON yet. Compiler versions:
* CS2007q3: Working NEON
* CS2008q1: Broken NEON
* CS2009q1: Partially Working NEON.

Generally the CS2007q3 release is recommended. The newest release does have better support for vectorizing integer and floating point computations on the NEON, but this has proven to be buggy.

Inorder to instruct the compiler to produce NEON / VFP code you should use the following compile flags: -mfpu=neon -mfloat-abi=softfp, or -mfpu=vfp -mfloat-abi=softfp. Unfortunately the prebuilt toolchains do not support the passing / returning of values in floating point registers (i talk about this some more in the Transfers section), there is however a patch being tested that supports hardfp and may be included in future toolchains. Additionally, If you want the compiler to attempt to vectorize your integer / floating point code for the NEON you should add: -ftree-vectorize to your flags.

Therefore i recommend the following flags: -O3 -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -fsingle-precision-constant

== VFP-Lite RunFast ==
The VFP-Lite has one saving grace, under the correct circumstances some of its instructions will be executed in the NEON coprocessor and will gain benefits of doing so. Inorder for this to occur the following constraints must be met:
* RunFast mode must be enabled
* Must be single precision floating point operands
* Must not be a vector instruction (GCC doesn't appear to use this feature, so don't worry about it)

Runfast mode is enabled when the following conditions are present:
* subnormal numbers are being flushed to zero
* default NaN mode is active
* no floating point exceptions are enabled

At the present time, it is unsure to me whether Runfast mode will be enabled by default in the Angstrom distribution. If it is not you can use the following C code to enforce it:

<source lang="c">
void enable_runfast()
{
static const unsigned int x = 0x04086060;
static const unsigned int y = 0x03000000;
int r;
asm volatile (
"fmrx %0, fpscr \n\t" //r0 = FPSCR
"and %0, %0, %1 \n\t" //r0 = r0 & 0x04086060
"orr %0, %0, %2 \n\t" //r0 = r0 | 0x03000000
"fmxr fpscr, %0 \n\t" //FPSCR = r0
: "=r"(r)
: "r"(x), "r"(y)
);
}</source>

The instructions that are executed on the NFP are: FADDS, FSUBS, FABSS, FNEGS, FMULS, FNMULS, FMACS, FNMACS, FMSCS, FNMSCS, FCMPS, FCMPES, FCMPZS, FCMPEZS, FUITOS, FSITOS, FTOUIS, FTOSIS, FTOUIZS, FTOSIZS, FSHTOS, FSLTOS, FUHTOS, FULTOS, FTOSHS, FTOSLS, FTOUHS, FTOULS.

== Single Precision Constants ==
One important and easy optimization is to make sure that single precision constants are being used. By default this is not the case, instead a double precision constant is being used, so all related operations involving that constant require double precision instructions and cannot be executed on the NEON. eg

<source lang="c">
float foo(float x)
{
return (2.123 * x);
}</source>

might end up the same as:

<source lang="c">
float foo(float x)
{
double dx = (double) x;
double dy = (double) 2.123;
double dr = dx * dy;
float r = (float) dr;
return r;
}</source>

You can enforce single precision constants by including the compiler flag: '''-fsingle-precision-constant''', alternatively you can append an 'f' to the end of each constant. ie 2.123f

== NFP / VFP to ARM Transfers ==
Probably the biggest bottleneck in the architecture is that inorder to transfer a number from the VFP / NFP registers onto the ARM you must stall both the ARM and NFP / VFP for >20 cycles. This is particularly troublesome because this is how GCC supplies arguments and recieves returns from functions. Possibly The best way to minimize operand passing stalls is to make the floating point functions inline.

Another source of NFP / VFP - ARM transfers are conditional branches that depend on floating point numbers. You can do the condition on the VFP but inorder to branch the flags must be sent from the VFP to the ARM. For very simple branches your best bet is to not branch at all and instead use arithmetic. ie
<source lang="c">if (x < 0) {x += 1.1244;}</source>
Is the same as:
<source lang="c">x = x + (x < 0) * 1.1244</source>
However you might want to keep a close eye on what the compiler actually produces with the above code.

One interesting fact is that using stores and loads do not cause a stall. So aslong as you don't need the result straight away you can hide the 20 cycle latency. Instead of doing a transfer you; store your NFP / VFP result to memory, do some work on the ARM, then load the result back onto the ARM without penalty. ie
<source lang="c">void foo(float *x, float *r)
{
*r = 123 + *x;
}

void bar(float *x, float *r)
{
*r = 546 + *x;
}

void main()
{
float x = 10;
float y, z;
foo(&x, &y)

//do ~20 cycles of ARM work

bar(&y, &z);

}</source>

== NEON SIMD ==
The NEON unit is similar to the MMX and SSE extensions found on X86 processors, it is optimized for Single Instruction Multiple Data (SIMD) operations.
The NEON unit has 2 floating point pipelines, an integer pipeline and a 128bit load/store/permute pipeline. When properly utilized it is a very powerful coprocessor. Unfortunately GCC does a rather poor job of vectorizing code for the NEON unit. To get the best performance you should use either the intrinsics provided in the "arm_neon.h" header or hand written assembly.

== Summary ==
Therefore, Inorder to achieve the best floating point performance on the Pandora:
* Only use single precision floating point
* Use single precision constants
* Enable RunFast mode
* Inline floating point code (unless its very large)
* Minimize Conditional Branches
* Pass Arguments via pointers instead of by value and do integer work in between function calls.
* Use NEON intrinsics / ASM for vectoriseable code.

Development tutorials

2009-07-25T07:22:37Z

Adventus:

== ARM Cortex A8 Tutorials ==
* [[Floating Point Optimization]]

== SDL Tutorials ==

These tutorials assume you know the basics of C++ programming, and know your way around a C++ compiler.

* [http://www.lazyfoo.net/SDL_tutorials/index.php Lazy Foo's Tutorials]. Not Pandora specific, but a good guide to getting your programming environment set up, along with many SDL tutorials.
* [http://iki.fi/sol/gp/ Sol's Graphics for beginners]. Not Pandora specific, but a good place to get started with SDL graphics coding.

==OpenGL on the Pandora==

*[[OpenGL ES 1.1 Tutorial]]

*[[OpenGL ES 2.0 Tutorial]]

*[[Combining OpenGL ES 1.1 and SDL to create a window on the Pandora]]

== The Kernel ==
* [[Kernel build instructions|Compiling the Kernel from Git]]
* [[Kernel interface|Kernel Interface]]

== Matchbox Window Manager ==

* [[Matchbox|Matchbox version]]
* [[xoo on ubuntu|Setting up xoo on Ubuntu 8.04/8.10]] (Theme Testing and Development)

== See Also ==

* [[Development Tools]]

[[Category:Development]]

Floating Point Optimization

2009-07-25T07:16:23Z

Adventus:

Floating Point Optimization

2009-07-25T07:04:42Z

Adventus:

Floating Point Optimization

2009-07-25T06:57:34Z

Adventus:

Floating Point Optimization

2009-07-25T06:41:49Z

Adventus: New page: == Introduction == In the past it was rare for an embedded processor to have dedicated floating point hardware, this usually limited you to either using fixed point math (which can be very...

Software projects

2009-07-02T23:56:34Z

Adventus: /* Other programs */

See the [[Port Requests]] article for open-source projects which ''could'' be ported but have not been taken on by anyone yet.

== Operating Systems ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Android Omap
|[http://elinux.org/Android_on_OMAP Link]
|wip
|
|
|-
|Angstrom Linux
|[http://www.angstrom-distribution.org/ Link]
|Working build, not completed
|
|
|-
|AROS Arm
|[http://projects.powerdeveloper.org/project/imx515/735 Link]
|wip
|
|
|-
|FreeBSD
|[http://wiki.freebsd.org/FreeBSD/arm/OMAP Link]
|wip
|
|
|-
|Gentoo Linux
|[http://gentoo.openpandora.org Link]
|Working build, not completed
|javaJake, Viridior
|IRC: (FreeNode) #gentoo-pandora
|-
|HaikuOS
|[http://www.haiku-os.org Link]
|wip
|
|
|-
|Ubuntu ARM
|[http://www.ubuntu.com/products/whatisubuntu/arm Link]
|wip
|
|
|-
|Fedora ARM
|
|Unknown
|
|
|}

== Games ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Abuse
|[http://abuse.zoy.org/ Link]
|working build
|Cpasjuste
|2D Platform
|-
|Battle for Wesnoth v1.6.2
|[http://www.gp32x.com/board/index.php?showtopic=47936 Link]
|working build
|Cpasjuste
|Strategy
|-
|BattleJewels
|
|Completed build for GP2X, WIP for Pandora
|Skeezix
|Logical
|-
|BlobWars
|[http://www.parallelrealities.co.uk/projects/blobWars.php Link]
|working build
|Cpasjuste
|2D Platform
|-
|Caster
|[http://www.gp32x.com/board/index.php?showtopic=46813 Link]
|Working build (tested on PC)
|Svartalf
|RPG
|-
|Descent 1 (d1x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|Descent 2 (d2x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|FHeroes Port (Heroes Of Might And Magic 2)
|[http://www.gp32x.com/board/index.php?showtopic=47553 Link]
|Working build
|Pickle
|Strategy
|-
|FreeCiv 2.1.9
|[http://freeciv.wikia.com/wiki/Main_Page Link]
|Working build
|Cpasjuste
|Strategy
|-
|Galactic Artifact
|[http://www.gp32x.com/board/index.php?showtopic=46836 Link]
|Working build
|Trevor Bradley
|Strategy
|-
|Giannas Return
|[http://www.gianas-return.de/ Link]
|Working
|Giannas Team
|Arcade
|-
|Gravity Blocks
|[http://www.gp32x.com/board/index.php?showtopic=47662 Link]
|wip (early in developement)
|Awekening
|Arcade
|-
|Homeworld Port
|[http://www.gp32x.com/board/index.php?showtopic=47565 Link]
|wip
|LinuxHacker
|Simulation
|-
|Human Condition (was TINCS)
|[http://www.gp32x.com/board/index.php?showtopic=46487 Link1][http://www.youtube.com/user/ButtermanHimself Link2]
|wip
|Butterman
|FPP
|-
|Lerp
|[http://grapefruitopia.com/lerp/ Link]
|working build
|benjymous
|2D physics puzzle platformer
|-
|Lord of the Rings Port
|[http://www.gp32x.com/board/index.php?showtopic=46792&hl= Link]
|Unknown
|Daeglin
|RPG
|-
|Monster!
|[http://christophsdevblog.blogspot.com/ Link]
|wip
|Chris R
|Arcade
|-
|NAEV
|[http://code.google.com/p/naev/ Link]
|wip (waiting for pandora to finish and test)
|bobbens
|Action/RPG/Sim
|-
|Nails Adventure
|[http://www.gp32x.com/board/index.php?showtopic=46961 Link]
|wip
|jsmtux/Mr. Gonzo
|
|-
|OpenLiero (Liero)
|
|working build, need to be polished
|Pickle
|Shoot'Em Up
|-
|OpenTyrian
|[http://code.google.com/p/opentyrian/ Link]
|working build
|Cpasjuste
|Shoot'Em Up
|-
|Pandora Panic!
|[http://www.youtube.com/watch?v=y9d6UXhQP6o Link]
|Working build
|PokeParadox / GP32X Community
|Arcade
|-
|Pandora Pool Panic
|[http://www.gp32x.com/board/index.php?showtopic=46996 Link]
|Almost Finished
|Unfathomable Depths
|Arcade
|-
|PanMMO - Pandora MMO Game via Internet
|[http://www.youtube.com/user/enirya Link]
|wip
|Enirya
|RPG
|-
|Powermanga
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Quake 1
|
|working build
|Pickle
|FPP
|-
|Quake 2
|
|working build
|Pickle
|FPP
|-
|Quake 3
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|FPP
|-
|Quake 3
|
|working build
|Pickle
|FPP
|-
|Reminiscence (flashback)
|[http://cyxdown.free.fr/reminiscence/ Link]
|working build
|Cpasjuste
|Action/Adventure
|-
|Rise of The Triad
|[http://www.gp32x.com/board/index.php?showtopic=47931 Link]
|wip
|arrrgh
|FPP
|-
|Super Lumenal
|[http://www.youtube.com/watch?v=sZHi3YT3xuE&feature=channel_page Link]
|wip
|Adventus
|Arcade
|-
|SuperTux 1
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|SuperTux 2
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|Tecnoballz
|[http://mydedibox.fr/_stuff/pandora/ Link]
|Working build
|Cpasjuste
|
|-
|Teeworlds
|[http://www.teeworlds.com/ Link]
|wip
|
|Arcade
|-
|The Mana World
|[http://www.themanaworld.org/ Link]
|Working build
|Cpasjuste
|MMORPG
|-
|uHexen2: Hammer of Thyrion
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Ur-Quan Masters
|[http://www.gp32x.com/board/index.php?showtopic=43625&st=165&p=673047&#entry673047 Link]
|Working build
|
|Space Exploration
|-
|We Come In Peace
|[http://www.gp32x.com/board/index.php?showtopic=43655 Link]
|working build
|Otaco
|Strategy
|-
|Stratagus
|[http://stratagus.sourceforge.net/ Link]
|working build
|Cpasjuste
|RTS Engine
|-
|Where in world is...
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|Casual
|-
|Wizzley Presto and the Mysterious Time Machine
|[http://www.30daygame.com/ Link]
|wip
|Craigix, Zodttd, Ruckage
|Arcade, 30 Day Game Competition
|-
|Wolf4SDL (Wolfenstein 3D)
|
|working build
|Pickle
|FPP
|-
|XSwing Plus
|[http://www.gp32x.com/board/index.php?s=&showtopic=43655&view=findpost&p=733021 Link]
|wip
|Tobse
|Arcade
|-
|ZEQ2Lite
|[http://www.gp32x.com/board/index.php?showtopic=47623&hl= Link]
|Work in progress
|MDave
|Dragonball Z Third Person Fighter/Shooter
|-
|Zdoom
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Zombd
|[http://www.gp32x.com/board/index.php?showtopic=46933 Link]
|Wip
|iprice/Mr Gonzo
|Shoot'Em Up
|}

== Emulators ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Emulated System
! Link
! Status
! Author/Port Author
! Notes
|-
|Caprice32
|Amstrad CPC
|[http://www.gp32x.com/board/index.php?showtopic=48140 Link1] [http://www.caprice32.cybercube.com/ Link2]
|wip
|hdonk
|
|-
|DosBox
|x86 DOS
|
|working build
|Pickle
|
|-
|FinalBurnAdvance
|CPS1/2/3/taito...
|[http://www.youtube.com/watch?v=06hjDLMBaf8 Link]
|
|Squidge
|
|-
|Frotz
|Z-Machine interpreter
|[http://www.cosam.org/computers/pandora/frotz-2.43.zip Link]
|
|
|
|-
|Fuse
|ZX Spectrum
|[http://www.cosam.org/computers/pandora/fuse-0.9.0.zip Link]
|working build
|SteveM
|
|-
|GnGeo
|SNK NeoGeo
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|gpSP
|Nintendo GBA
|
|wip
|ZodTTD
|
|-
|Hatari
|Atari ST
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|Jzintv
|Mattel Intellivision
|[http://www.gp32x.com/board/index.php?showtopic=48035 Link]
|
|WizardStan
|
|-
|MAME4All
|Arcade
|[http://www.youtube.com/user/franxism Link]
|
|Franxis
|
|-
|NeoPop
|SNK NeoGeo Pocket
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|NullDC
|Sega Dreamcast
|[http://www.gp32x.com/board/index.php?s=&showtopic=47065&view=findpost&p=709910 Link]
|Wip
|Zezu / drkIIraziel
|
|-
|PandaSNES
|Nintendo SNES
|[http://www.gp32x.com/board/index.php?showtopic=43213 Link]
|wip
|Squidge
|
|-
|Pandora-PSP
|Sony Playstation Portable
|[http://jayfoxrox.bplaced.net/pandora-psp/ Link]
|wip
|[[User:JayFoxRox|JayFoxRox]]
|
|-
|PAtari
|Atari 800
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PicoDrive
|Sega Genesis/CD/32x
|[http://www.youtube.com/watch?v=QDbLQI91510 Link]
|working build
|Notaz
|Fullspeed emulator
|-
|PSMS
|Sega Master System
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PSnes
|Nintendo SNES
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Psx4All
|Sony PlayStation
|[http://www.zodttd.com Link]
|Not Status, working build
|ZodTTD
|
|-
|ScummVM
|x86 Scumm engine games
|
|Working build
|DJ Willis
|Fullspeed emulator
|-
|SIMH
|old hardware
|[http://www.cosam.org/computers/pandora/simh-3.8.zip Link]
|working build
|SteveM
|
|-
|Temper
|NEC PC Engine
|[http://exophase.devzero.co.uk/ Link]
|wip
|Exophase
|Fullspeed emulator
|-
|Tempest
|Atari Jaguar
|[http://www.gp32x.com/board/index.php?showtopic=43119 Link]
|
|Firefox
|
|-
|Uae4All
|Amiga
|[http://www.gp32x.com/board/index.php?showtopic=44100 Link]
|Working build
|
|
|-
|XMAME
|Arcade
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|}

== Graphic Engines ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|GemRB (Infinity Engine)
|
|wip
|Adventus
|open-source implementation of Bioware's Infinity Engine, supports games including Baldurs Gate 2 and Planescape Torment.
|-
|GLES2D
|
|Wip
|Cpasjuste
|OpenGL ES 2D library
|-
|GL-WES-v2.0
|[http://code.google.com/p/gl-wes-v2/ link]
|Working Build
|Adventus
|Opensource OpenGL 2.0 driver built on OpenGL ES 2.0.
|-
|Irrlicht
|[http://irrlicht.sourceforge.net/] [http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=32538&start=45]
|working build
|Hybrid
|
|-
|NSS Engine
|[http://www.nosiestastudios.com/wiki/ Link1] [http://www.youtube.com/user/Prompt84 Link2]
|
|No Siesta Studios
|
|-
|OGRE Engine
|[http://www.gp32x.com/board/index.php?showtopic=46706 Link1] [http://www.youtube.com/watch?v=LDtUE5PIhV0 Link2]
|
|
|
|-
|Otaco Glost Engine
|[http://www.youtube.com/user/otacogloost Link]
|working
|Otaco
|
|-
|Quad-Ren 2D
|[http://quad-ren.sourceforge.net/index.php Link]
|
|Hessiess
|
|-
|SDL GLES
|[http://github.com/Cpasjuste/sdl-1.2.13_gles/tree Link]
|working
|Cpasjuste
|
|-
|XreaL
|[http://xreal.sourceforge.net/xrealwiki/ Link]
|
|Pickle [?]
|
|}

== Other programs ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|AbiWord - Word Processor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Claws Mail
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Epiphany Web Bowser
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|FireFox - Internet Browser
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GIMP - Image Editor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GMenu
|[http://www.youtube.com/watch?v=VYzi8gziC7E Link]
|Working build
|Pandora Team
|
|-
|Gnumeric Spreadsheet - Spreadsheet
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GoView
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Image Gallery
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Inside The Box
|[http://www.openpandora.pl Link1] [http://www.youtube.com/watch?v=uLMmJBDEs2E Link2]
|wip
|StreaK
|Pandora e-zine
|-
|IRC Client
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|LeafPad
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Matchbox Shell / GUI
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|MPlayer
|[http://www.gp32x.com/board/index.php?showtopic=41420 Link1] [http://www.youtube.com/watch?v=v9RAPNa-55k Link2]
|Working build
|Squidge
|
|-
|Math-NEON
|
|Wip
|Adventus
|cmath like library optimised for ARM NEON coprocessor.
|-
|Pandora Sync Suite
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|for Windows 9x/NT
|-
|Pangea GUI
|[http://www.gp32x.com/board/index.php?showtopic=45631&hl=pangea Link]
|WIP
|efegea
|Gmenu alternative
|-
|PDM
|[http://github.com/Cpasjuste/pdm/tree Link]
|
|Cpasjuste
|Light desktop manager for Pandora
|-
|PGui
|[http://github.com/Cpasjuste/pgui/tree Link]
|
|Cpasjuste
|Standard emulator fronted for Pandora
|-
|Pidgin - IM (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|PMenu
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|Minimal Menu for Pandora
|-
|PND Maker (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Qemu
|[http://www.nongnu.org/qemu/status.html Link]
|testing build
|Fabrice Bellard
|open source machine emulator and virtualizer
|-
|Scale
|[http://www.youtube.com/user/Zoxc64 Link]
|wip
|Zoxc64
|Minimal Menu for Pandora
|-
|Simple Dev Studio for Pandora
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|for Windows 9x/NT
|-
|[[TINXL]]
|[[TINXL]]
|
|
|Application stack for multiplayer internet games
|-
|[[TS2A]]
|[[TS2A]]
|Documentation only
||[[User:JayFoxRox|JayFoxRox]]
|Teamspeak 2 Alternative Client / Server, Needs developer
|-
|XMMS
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|ZiB Emulator Frontend
|[http://www.gp32x.com/board/index.php?showtopic=47203 Link1] [http://www.youtube.com/watch?v=UJvON8lCM3M Link2]
|
|Aimless_E
|
|}

== Demos / Technical Demos for OpenPandora ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|OpenGL Cell Shading
|[http://www.youtube.com/watch?v=cpAj0jHglGw Link]
|working build
|
|
|-
|OpenGL Demo with MP3 Playback
|[http://www.youtube.com/watch?v=hkx18kruRJs Link]
|working build
|
|
|-
|OpenGL Skull Demo
|[http://www.youtube.com/watch?v=qG7EDaZpyOo Link]
|working build
|
|
|-
|WaveDemo
|[http://www.youtube.com/watch?v=4wgEHFCq9Lo Link]
|Working
|Otaco
|
|}

Software projects

2009-07-02T23:55:47Z

Adventus: /* Other programs */

See the [[Port Requests]] article for open-source projects which ''could'' be ported but have not been taken on by anyone yet.

== Operating Systems ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Android Omap
|[http://elinux.org/Android_on_OMAP Link]
|wip
|
|
|-
|Angstrom Linux
|[http://www.angstrom-distribution.org/ Link]
|Working build, not completed
|
|
|-
|AROS Arm
|[http://projects.powerdeveloper.org/project/imx515/735 Link]
|wip
|
|
|-
|FreeBSD
|[http://wiki.freebsd.org/FreeBSD/arm/OMAP Link]
|wip
|
|
|-
|Gentoo Linux
|[http://gentoo.openpandora.org Link]
|Working build, not completed
|javaJake, Viridior
|IRC: (FreeNode) #gentoo-pandora
|-
|HaikuOS
|[http://www.haiku-os.org Link]
|wip
|
|
|-
|Ubuntu ARM
|[http://www.ubuntu.com/products/whatisubuntu/arm Link]
|wip
|
|
|-
|Fedora ARM
|
|Unknown
|
|
|}

== Games ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Abuse
|[http://abuse.zoy.org/ Link]
|working build
|Cpasjuste
|2D Platform
|-
|Battle for Wesnoth v1.6.2
|[http://www.gp32x.com/board/index.php?showtopic=47936 Link]
|working build
|Cpasjuste
|Strategy
|-
|BattleJewels
|
|Completed build for GP2X, WIP for Pandora
|Skeezix
|Logical
|-
|BlobWars
|[http://www.parallelrealities.co.uk/projects/blobWars.php Link]
|working build
|Cpasjuste
|2D Platform
|-
|Caster
|[http://www.gp32x.com/board/index.php?showtopic=46813 Link]
|Working build (tested on PC)
|Svartalf
|RPG
|-
|Descent 1 (d1x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|Descent 2 (d2x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|FHeroes Port (Heroes Of Might And Magic 2)
|[http://www.gp32x.com/board/index.php?showtopic=47553 Link]
|Working build
|Pickle
|Strategy
|-
|FreeCiv 2.1.9
|[http://freeciv.wikia.com/wiki/Main_Page Link]
|Working build
|Cpasjuste
|Strategy
|-
|Galactic Artifact
|[http://www.gp32x.com/board/index.php?showtopic=46836 Link]
|Working build
|Trevor Bradley
|Strategy
|-
|Giannas Return
|[http://www.gianas-return.de/ Link]
|Working
|Giannas Team
|Arcade
|-
|Gravity Blocks
|[http://www.gp32x.com/board/index.php?showtopic=47662 Link]
|wip (early in developement)
|Awekening
|Arcade
|-
|Homeworld Port
|[http://www.gp32x.com/board/index.php?showtopic=47565 Link]
|wip
|LinuxHacker
|Simulation
|-
|Human Condition (was TINCS)
|[http://www.gp32x.com/board/index.php?showtopic=46487 Link1][http://www.youtube.com/user/ButtermanHimself Link2]
|wip
|Butterman
|FPP
|-
|Lerp
|[http://grapefruitopia.com/lerp/ Link]
|working build
|benjymous
|2D physics puzzle platformer
|-
|Lord of the Rings Port
|[http://www.gp32x.com/board/index.php?showtopic=46792&hl= Link]
|Unknown
|Daeglin
|RPG
|-
|Monster!
|[http://christophsdevblog.blogspot.com/ Link]
|wip
|Chris R
|Arcade
|-
|NAEV
|[http://code.google.com/p/naev/ Link]
|wip (waiting for pandora to finish and test)
|bobbens
|Action/RPG/Sim
|-
|Nails Adventure
|[http://www.gp32x.com/board/index.php?showtopic=46961 Link]
|wip
|jsmtux/Mr. Gonzo
|
|-
|OpenLiero (Liero)
|
|working build, need to be polished
|Pickle
|Shoot'Em Up
|-
|OpenTyrian
|[http://code.google.com/p/opentyrian/ Link]
|working build
|Cpasjuste
|Shoot'Em Up
|-
|Pandora Panic!
|[http://www.youtube.com/watch?v=y9d6UXhQP6o Link]
|Working build
|PokeParadox / GP32X Community
|Arcade
|-
|Pandora Pool Panic
|[http://www.gp32x.com/board/index.php?showtopic=46996 Link]
|Almost Finished
|Unfathomable Depths
|Arcade
|-
|PanMMO - Pandora MMO Game via Internet
|[http://www.youtube.com/user/enirya Link]
|wip
|Enirya
|RPG
|-
|Powermanga
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Quake 1
|
|working build
|Pickle
|FPP
|-
|Quake 2
|
|working build
|Pickle
|FPP
|-
|Quake 3
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|FPP
|-
|Quake 3
|
|working build
|Pickle
|FPP
|-
|Reminiscence (flashback)
|[http://cyxdown.free.fr/reminiscence/ Link]
|working build
|Cpasjuste
|Action/Adventure
|-
|Rise of The Triad
|[http://www.gp32x.com/board/index.php?showtopic=47931 Link]
|wip
|arrrgh
|FPP
|-
|Super Lumenal
|[http://www.youtube.com/watch?v=sZHi3YT3xuE&feature=channel_page Link]
|wip
|Adventus
|Arcade
|-
|SuperTux 1
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|SuperTux 2
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|Tecnoballz
|[http://mydedibox.fr/_stuff/pandora/ Link]
|Working build
|Cpasjuste
|
|-
|Teeworlds
|[http://www.teeworlds.com/ Link]
|wip
|
|Arcade
|-
|The Mana World
|[http://www.themanaworld.org/ Link]
|Working build
|Cpasjuste
|MMORPG
|-
|uHexen2: Hammer of Thyrion
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Ur-Quan Masters
|[http://www.gp32x.com/board/index.php?showtopic=43625&st=165&p=673047&#entry673047 Link]
|Working build
|
|Space Exploration
|-
|We Come In Peace
|[http://www.gp32x.com/board/index.php?showtopic=43655 Link]
|working build
|Otaco
|Strategy
|-
|Stratagus
|[http://stratagus.sourceforge.net/ Link]
|working build
|Cpasjuste
|RTS Engine
|-
|Where in world is...
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|Casual
|-
|Wizzley Presto and the Mysterious Time Machine
|[http://www.30daygame.com/ Link]
|wip
|Craigix, Zodttd, Ruckage
|Arcade, 30 Day Game Competition
|-
|Wolf4SDL (Wolfenstein 3D)
|
|working build
|Pickle
|FPP
|-
|XSwing Plus
|[http://www.gp32x.com/board/index.php?s=&showtopic=43655&view=findpost&p=733021 Link]
|wip
|Tobse
|Arcade
|-
|ZEQ2Lite
|[http://www.gp32x.com/board/index.php?showtopic=47623&hl= Link]
|Work in progress
|MDave
|Dragonball Z Third Person Fighter/Shooter
|-
|Zdoom
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Zombd
|[http://www.gp32x.com/board/index.php?showtopic=46933 Link]
|Wip
|iprice/Mr Gonzo
|Shoot'Em Up
|}

== Emulators ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Emulated System
! Link
! Status
! Author/Port Author
! Notes
|-
|Caprice32
|Amstrad CPC
|[http://www.gp32x.com/board/index.php?showtopic=48140 Link1] [http://www.caprice32.cybercube.com/ Link2]
|wip
|hdonk
|
|-
|DosBox
|x86 DOS
|
|working build
|Pickle
|
|-
|FinalBurnAdvance
|CPS1/2/3/taito...
|[http://www.youtube.com/watch?v=06hjDLMBaf8 Link]
|
|Squidge
|
|-
|Frotz
|Z-Machine interpreter
|[http://www.cosam.org/computers/pandora/frotz-2.43.zip Link]
|
|
|
|-
|Fuse
|ZX Spectrum
|[http://www.cosam.org/computers/pandora/fuse-0.9.0.zip Link]
|working build
|SteveM
|
|-
|GnGeo
|SNK NeoGeo
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|gpSP
|Nintendo GBA
|
|wip
|ZodTTD
|
|-
|Hatari
|Atari ST
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|Jzintv
|Mattel Intellivision
|[http://www.gp32x.com/board/index.php?showtopic=48035 Link]
|
|WizardStan
|
|-
|MAME4All
|Arcade
|[http://www.youtube.com/user/franxism Link]
|
|Franxis
|
|-
|NeoPop
|SNK NeoGeo Pocket
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|NullDC
|Sega Dreamcast
|[http://www.gp32x.com/board/index.php?s=&showtopic=47065&view=findpost&p=709910 Link]
|Wip
|Zezu / drkIIraziel
|
|-
|PandaSNES
|Nintendo SNES
|[http://www.gp32x.com/board/index.php?showtopic=43213 Link]
|wip
|Squidge
|
|-
|Pandora-PSP
|Sony Playstation Portable
|[http://jayfoxrox.bplaced.net/pandora-psp/ Link]
|wip
|[[User:JayFoxRox|JayFoxRox]]
|
|-
|PAtari
|Atari 800
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PicoDrive
|Sega Genesis/CD/32x
|[http://www.youtube.com/watch?v=QDbLQI91510 Link]
|working build
|Notaz
|Fullspeed emulator
|-
|PSMS
|Sega Master System
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PSnes
|Nintendo SNES
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Psx4All
|Sony PlayStation
|[http://www.zodttd.com Link]
|Not Status, working build
|ZodTTD
|
|-
|ScummVM
|x86 Scumm engine games
|
|Working build
|DJ Willis
|Fullspeed emulator
|-
|SIMH
|old hardware
|[http://www.cosam.org/computers/pandora/simh-3.8.zip Link]
|working build
|SteveM
|
|-
|Temper
|NEC PC Engine
|[http://exophase.devzero.co.uk/ Link]
|wip
|Exophase
|Fullspeed emulator
|-
|Tempest
|Atari Jaguar
|[http://www.gp32x.com/board/index.php?showtopic=43119 Link]
|
|Firefox
|
|-
|Uae4All
|Amiga
|[http://www.gp32x.com/board/index.php?showtopic=44100 Link]
|Working build
|
|
|-
|XMAME
|Arcade
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|}

== Graphic Engines ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|GemRB (Infinity Engine)
|
|wip
|Adventus
|open-source implementation of Bioware's Infinity Engine, supports games including Baldurs Gate 2 and Planescape Torment.
|-
|GLES2D
|
|Wip
|Cpasjuste
|OpenGL ES 2D library
|-
|GL-WES-v2.0
|[http://code.google.com/p/gl-wes-v2/ link]
|Working Build
|Adventus
|Opensource OpenGL 2.0 driver built on OpenGL ES 2.0.
|-
|Irrlicht
|[http://irrlicht.sourceforge.net/] [http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=32538&start=45]
|working build
|Hybrid
|
|-
|NSS Engine
|[http://www.nosiestastudios.com/wiki/ Link1] [http://www.youtube.com/user/Prompt84 Link2]
|
|No Siesta Studios
|
|-
|OGRE Engine
|[http://www.gp32x.com/board/index.php?showtopic=46706 Link1] [http://www.youtube.com/watch?v=LDtUE5PIhV0 Link2]
|
|
|
|-
|Otaco Glost Engine
|[http://www.youtube.com/user/otacogloost Link]
|working
|Otaco
|
|-
|Quad-Ren 2D
|[http://quad-ren.sourceforge.net/index.php Link]
|
|Hessiess
|
|-
|SDL GLES
|[http://github.com/Cpasjuste/sdl-1.2.13_gles/tree Link]
|working
|Cpasjuste
|
|-
|XreaL
|[http://xreal.sourceforge.net/xrealwiki/ Link]
|
|Pickle [?]
|
|}

== Other programs ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|AbiWord - Word Processor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Claws Mail
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Epiphany Web Bowser
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|FireFox - Internet Browser
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GIMP - Image Editor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GMenu
|[http://www.youtube.com/watch?v=VYzi8gziC7E Link]
|Working build
|Pandora Team
|
|-
|Gnumeric Spreadsheet - Spreadsheet
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GoView
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Image Gallery
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Inside The Box
|[http://www.openpandora.pl Link1] [http://www.youtube.com/watch?v=uLMmJBDEs2E Link2]
|wip
|StreaK
|Pandora e-zine
|-
|IRC Client
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|LeafPad
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Matchbox Shell / GUI
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|MPlayer
|[http://www.gp32x.com/board/index.php?showtopic=41420 Link1] [http://www.youtube.com/watch?v=v9RAPNa-55k Link2]
|Working build
|Squidge
|
|-
|math_neon
|
|Wip
|Adventus
|cmath like library optimised for ARM NEON coprocessor.
|-
|Pandora Sync Suite
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|for Windows 9x/NT
|-
|Pangea GUI
|[http://www.gp32x.com/board/index.php?showtopic=45631&hl=pangea Link]
|WIP
|efegea
|Gmenu alternative
|-
|PDM
|[http://github.com/Cpasjuste/pdm/tree Link]
|
|Cpasjuste
|Light desktop manager for Pandora
|-
|PGui
|[http://github.com/Cpasjuste/pgui/tree Link]
|
|Cpasjuste
|Standard emulator fronted for Pandora
|-
|Pidgin - IM (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|PMenu
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|Minimal Menu for Pandora
|-
|PND Maker (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Qemu
|[http://www.nongnu.org/qemu/status.html Link]
|testing build
|Fabrice Bellard
|open source machine emulator and virtualizer
|-
|Scale
|[http://www.youtube.com/user/Zoxc64 Link]
|wip
|Zoxc64
|Minimal Menu for Pandora
|-
|Simple Dev Studio for Pandora
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|for Windows 9x/NT
|-
|[[TINXL]]
|[[TINXL]]
|
|
|Application stack for multiplayer internet games
|-
|[[TS2A]]
|[[TS2A]]
|Documentation only
||[[User:JayFoxRox|JayFoxRox]]
|Teamspeak 2 Alternative Client / Server, Needs developer
|-
|XMMS
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|ZiB Emulator Frontend
|[http://www.gp32x.com/board/index.php?showtopic=47203 Link1] [http://www.youtube.com/watch?v=UJvON8lCM3M Link2]
|
|Aimless_E
|
|}

== Demos / Technical Demos for OpenPandora ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|OpenGL Cell Shading
|[http://www.youtube.com/watch?v=cpAj0jHglGw Link]
|working build
|
|
|-
|OpenGL Demo with MP3 Playback
|[http://www.youtube.com/watch?v=hkx18kruRJs Link]
|working build
|
|
|-
|OpenGL Skull Demo
|[http://www.youtube.com/watch?v=qG7EDaZpyOo Link]
|working build
|
|
|-
|WaveDemo
|[http://www.youtube.com/watch?v=4wgEHFCq9Lo Link]
|Working
|Otaco
|
|}

Software projects

2009-07-02T23:53:33Z

Adventus: /* Graphic Engines */

See the [[Port Requests]] article for open-source projects which ''could'' be ported but have not been taken on by anyone yet.

== Operating Systems ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Android Omap
|[http://elinux.org/Android_on_OMAP Link]
|wip
|
|
|-
|Angstrom Linux
|[http://www.angstrom-distribution.org/ Link]
|Working build, not completed
|
|
|-
|AROS Arm
|[http://projects.powerdeveloper.org/project/imx515/735 Link]
|wip
|
|
|-
|FreeBSD
|[http://wiki.freebsd.org/FreeBSD/arm/OMAP Link]
|wip
|
|
|-
|Gentoo Linux
|[http://gentoo.openpandora.org Link]
|Working build, not completed
|javaJake, Viridior
|IRC: (FreeNode) #gentoo-pandora
|-
|HaikuOS
|[http://www.haiku-os.org Link]
|wip
|
|
|-
|Ubuntu ARM
|[http://www.ubuntu.com/products/whatisubuntu/arm Link]
|wip
|
|
|-
|Fedora ARM
|
|Unknown
|
|
|}

== Games ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Abuse
|[http://abuse.zoy.org/ Link]
|working build
|Cpasjuste
|2D Platform
|-
|Battle for Wesnoth v1.6.2
|[http://www.gp32x.com/board/index.php?showtopic=47936 Link]
|working build
|Cpasjuste
|Strategy
|-
|BattleJewels
|
|Completed build for GP2X, WIP for Pandora
|Skeezix
|Logical
|-
|BlobWars
|[http://www.parallelrealities.co.uk/projects/blobWars.php Link]
|working build
|Cpasjuste
|2D Platform
|-
|Caster
|[http://www.gp32x.com/board/index.php?showtopic=46813 Link]
|Working build (tested on PC)
|Svartalf
|RPG
|-
|Descent 1 (d1x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|Descent 2 (d2x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|FHeroes Port (Heroes Of Might And Magic 2)
|[http://www.gp32x.com/board/index.php?showtopic=47553 Link]
|Working build
|Pickle
|Strategy
|-
|FreeCiv 2.1.9
|[http://freeciv.wikia.com/wiki/Main_Page Link]
|Working build
|Cpasjuste
|Strategy
|-
|Galactic Artifact
|[http://www.gp32x.com/board/index.php?showtopic=46836 Link]
|Working build
|Trevor Bradley
|Strategy
|-
|Giannas Return
|[http://www.gianas-return.de/ Link]
|Working
|Giannas Team
|Arcade
|-
|Gravity Blocks
|[http://www.gp32x.com/board/index.php?showtopic=47662 Link]
|wip (early in developement)
|Awekening
|Arcade
|-
|Homeworld Port
|[http://www.gp32x.com/board/index.php?showtopic=47565 Link]
|wip
|LinuxHacker
|Simulation
|-
|Human Condition (was TINCS)
|[http://www.gp32x.com/board/index.php?showtopic=46487 Link1][http://www.youtube.com/user/ButtermanHimself Link2]
|wip
|Butterman
|FPP
|-
|Lerp
|[http://grapefruitopia.com/lerp/ Link]
|working build
|benjymous
|2D physics puzzle platformer
|-
|Lord of the Rings Port
|[http://www.gp32x.com/board/index.php?showtopic=46792&hl= Link]
|Unknown
|Daeglin
|RPG
|-
|Monster!
|[http://christophsdevblog.blogspot.com/ Link]
|wip
|Chris R
|Arcade
|-
|NAEV
|[http://code.google.com/p/naev/ Link]
|wip (waiting for pandora to finish and test)
|bobbens
|Action/RPG/Sim
|-
|Nails Adventure
|[http://www.gp32x.com/board/index.php?showtopic=46961 Link]
|wip
|jsmtux/Mr. Gonzo
|
|-
|OpenLiero (Liero)
|
|working build, need to be polished
|Pickle
|Shoot'Em Up
|-
|OpenTyrian
|[http://code.google.com/p/opentyrian/ Link]
|working build
|Cpasjuste
|Shoot'Em Up
|-
|Pandora Panic!
|[http://www.youtube.com/watch?v=y9d6UXhQP6o Link]
|Working build
|PokeParadox / GP32X Community
|Arcade
|-
|Pandora Pool Panic
|[http://www.gp32x.com/board/index.php?showtopic=46996 Link]
|Almost Finished
|Unfathomable Depths
|Arcade
|-
|PanMMO - Pandora MMO Game via Internet
|[http://www.youtube.com/user/enirya Link]
|wip
|Enirya
|RPG
|-
|Powermanga
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Quake 1
|
|working build
|Pickle
|FPP
|-
|Quake 2
|
|working build
|Pickle
|FPP
|-
|Quake 3
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|FPP
|-
|Quake 3
|
|working build
|Pickle
|FPP
|-
|Reminiscence (flashback)
|[http://cyxdown.free.fr/reminiscence/ Link]
|working build
|Cpasjuste
|Action/Adventure
|-
|Rise of The Triad
|[http://www.gp32x.com/board/index.php?showtopic=47931 Link]
|wip
|arrrgh
|FPP
|-
|Super Lumenal
|[http://www.youtube.com/watch?v=sZHi3YT3xuE&feature=channel_page Link]
|wip
|Adventus
|Arcade
|-
|SuperTux 1
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|SuperTux 2
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|Tecnoballz
|[http://mydedibox.fr/_stuff/pandora/ Link]
|Working build
|Cpasjuste
|
|-
|Teeworlds
|[http://www.teeworlds.com/ Link]
|wip
|
|Arcade
|-
|The Mana World
|[http://www.themanaworld.org/ Link]
|Working build
|Cpasjuste
|MMORPG
|-
|uHexen2: Hammer of Thyrion
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Ur-Quan Masters
|[http://www.gp32x.com/board/index.php?showtopic=43625&st=165&p=673047&#entry673047 Link]
|Working build
|
|Space Exploration
|-
|We Come In Peace
|[http://www.gp32x.com/board/index.php?showtopic=43655 Link]
|working build
|Otaco
|Strategy
|-
|Stratagus
|[http://stratagus.sourceforge.net/ Link]
|working build
|Cpasjuste
|RTS Engine
|-
|Where in world is...
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|Casual
|-
|Wizzley Presto and the Mysterious Time Machine
|[http://www.30daygame.com/ Link]
|wip
|Craigix, Zodttd, Ruckage
|Arcade, 30 Day Game Competition
|-
|Wolf4SDL (Wolfenstein 3D)
|
|working build
|Pickle
|FPP
|-
|XSwing Plus
|[http://www.gp32x.com/board/index.php?s=&showtopic=43655&view=findpost&p=733021 Link]
|wip
|Tobse
|Arcade
|-
|ZEQ2Lite
|[http://www.gp32x.com/board/index.php?showtopic=47623&hl= Link]
|Work in progress
|MDave
|Dragonball Z Third Person Fighter/Shooter
|-
|Zdoom
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Zombd
|[http://www.gp32x.com/board/index.php?showtopic=46933 Link]
|Wip
|iprice/Mr Gonzo
|Shoot'Em Up
|}

== Emulators ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Emulated System
! Link
! Status
! Author/Port Author
! Notes
|-
|Caprice32
|Amstrad CPC
|[http://www.gp32x.com/board/index.php?showtopic=48140 Link1] [http://www.caprice32.cybercube.com/ Link2]
|wip
|hdonk
|
|-
|DosBox
|x86 DOS
|
|working build
|Pickle
|
|-
|FinalBurnAdvance
|CPS1/2/3/taito...
|[http://www.youtube.com/watch?v=06hjDLMBaf8 Link]
|
|Squidge
|
|-
|Frotz
|Z-Machine interpreter
|[http://www.cosam.org/computers/pandora/frotz-2.43.zip Link]
|
|
|
|-
|Fuse
|ZX Spectrum
|[http://www.cosam.org/computers/pandora/fuse-0.9.0.zip Link]
|working build
|SteveM
|
|-
|GnGeo
|SNK NeoGeo
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|gpSP
|Nintendo GBA
|
|wip
|ZodTTD
|
|-
|Hatari
|Atari ST
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|Jzintv
|Mattel Intellivision
|[http://www.gp32x.com/board/index.php?showtopic=48035 Link]
|
|WizardStan
|
|-
|MAME4All
|Arcade
|[http://www.youtube.com/user/franxism Link]
|
|Franxis
|
|-
|NeoPop
|SNK NeoGeo Pocket
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|NullDC
|Sega Dreamcast
|[http://www.gp32x.com/board/index.php?s=&showtopic=47065&view=findpost&p=709910 Link]
|Wip
|Zezu / drkIIraziel
|
|-
|PandaSNES
|Nintendo SNES
|[http://www.gp32x.com/board/index.php?showtopic=43213 Link]
|wip
|Squidge
|
|-
|Pandora-PSP
|Sony Playstation Portable
|[http://jayfoxrox.bplaced.net/pandora-psp/ Link]
|wip
|[[User:JayFoxRox|JayFoxRox]]
|
|-
|PAtari
|Atari 800
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PicoDrive
|Sega Genesis/CD/32x
|[http://www.youtube.com/watch?v=QDbLQI91510 Link]
|working build
|Notaz
|Fullspeed emulator
|-
|PSMS
|Sega Master System
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PSnes
|Nintendo SNES
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Psx4All
|Sony PlayStation
|[http://www.zodttd.com Link]
|Not Status, working build
|ZodTTD
|
|-
|ScummVM
|x86 Scumm engine games
|
|Working build
|DJ Willis
|Fullspeed emulator
|-
|SIMH
|old hardware
|[http://www.cosam.org/computers/pandora/simh-3.8.zip Link]
|working build
|SteveM
|
|-
|Temper
|NEC PC Engine
|[http://exophase.devzero.co.uk/ Link]
|wip
|Exophase
|Fullspeed emulator
|-
|Tempest
|Atari Jaguar
|[http://www.gp32x.com/board/index.php?showtopic=43119 Link]
|
|Firefox
|
|-
|Uae4All
|Amiga
|[http://www.gp32x.com/board/index.php?showtopic=44100 Link]
|Working build
|
|
|-
|XMAME
|Arcade
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|}

== Graphic Engines ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|GemRB (Infinity Engine)
|
|wip
|Adventus
|open-source implementation of Bioware's Infinity Engine, supports games including Baldurs Gate 2 and Planescape Torment.
|-
|GLES2D
|
|Wip
|Cpasjuste
|OpenGL ES 2D library
|-
|GL-WES-v2.0
|[http://code.google.com/p/gl-wes-v2/ link]
|Working Build
|Adventus
|Opensource OpenGL 2.0 driver built on OpenGL ES 2.0.
|-
|Irrlicht
|[http://irrlicht.sourceforge.net/] [http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=32538&start=45]
|working build
|Hybrid
|
|-
|NSS Engine
|[http://www.nosiestastudios.com/wiki/ Link1] [http://www.youtube.com/user/Prompt84 Link2]
|
|No Siesta Studios
|
|-
|OGRE Engine
|[http://www.gp32x.com/board/index.php?showtopic=46706 Link1] [http://www.youtube.com/watch?v=LDtUE5PIhV0 Link2]
|
|
|
|-
|Otaco Glost Engine
|[http://www.youtube.com/user/otacogloost Link]
|working
|Otaco
|
|-
|Quad-Ren 2D
|[http://quad-ren.sourceforge.net/index.php Link]
|
|Hessiess
|
|-
|SDL GLES
|[http://github.com/Cpasjuste/sdl-1.2.13_gles/tree Link]
|working
|Cpasjuste
|
|-
|XreaL
|[http://xreal.sourceforge.net/xrealwiki/ Link]
|
|Pickle [?]
|
|}

== Other programs ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|AbiWord - Word Processor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Claws Mail
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Epiphany Web Bowser
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|FireFox - Internet Browser
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GIMP - Image Editor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GMenu
|[http://www.youtube.com/watch?v=VYzi8gziC7E Link]
|Working build
|Pandora Team
|
|-
|Gnumeric Spreadsheet - Spreadsheet
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GoView
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Image Gallery
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Inside The Box
|[http://www.openpandora.pl Link1] [http://www.youtube.com/watch?v=uLMmJBDEs2E Link2]
|wip
|StreaK
|Pandora e-zine
|-
|IRC Client
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|LeafPad
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Matchbox Shell / GUI
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|MPlayer
|[http://www.gp32x.com/board/index.php?showtopic=41420 Link1] [http://www.youtube.com/watch?v=v9RAPNa-55k Link2]
|Working build
|Squidge
|
|-
|Pandora Sync Suite
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|for Windows 9x/NT
|-
|Pangea GUI
|[http://www.gp32x.com/board/index.php?showtopic=45631&hl=pangea Link]
|WIP
|efegea
|Gmenu alternative
|-
|PDM
|[http://github.com/Cpasjuste/pdm/tree Link]
|
|Cpasjuste
|Light desktop manager for Pandora
|-
|PGui
|[http://github.com/Cpasjuste/pgui/tree Link]
|
|Cpasjuste
|Standard emulator fronted for Pandora
|-
|Pidgin - IM (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|PMenu
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|Minimal Menu for Pandora
|-
|PND Maker (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Qemu
|[http://www.nongnu.org/qemu/status.html Link]
|testing build
|Fabrice Bellard
|open source machine emulator and virtualizer
|-
|Scale
|[http://www.youtube.com/user/Zoxc64 Link]
|wip
|Zoxc64
|Minimal Menu for Pandora
|-
|Simple Dev Studio for Pandora
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|for Windows 9x/NT
|-
|[[TINXL]]
|[[TINXL]]
|
|
|Application stack for multiplayer internet games
|-
|[[TS2A]]
|[[TS2A]]
|Documentation only
||[[User:JayFoxRox|JayFoxRox]]
|Teamspeak 2 Alternative Client / Server, Needs developer
|-
|XMMS
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|ZiB Emulator Frontend
|[http://www.gp32x.com/board/index.php?showtopic=47203 Link1] [http://www.youtube.com/watch?v=UJvON8lCM3M Link2]
|
|Aimless_E
|
|}

== Demos / Technical Demos for OpenPandora ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|OpenGL Cell Shading
|[http://www.youtube.com/watch?v=cpAj0jHglGw Link]
|working build
|
|
|-
|OpenGL Demo with MP3 Playback
|[http://www.youtube.com/watch?v=hkx18kruRJs Link]
|working build
|
|
|-
|OpenGL Skull Demo
|[http://www.youtube.com/watch?v=qG7EDaZpyOo Link]
|working build
|
|
|-
|WaveDemo
|[http://www.youtube.com/watch?v=4wgEHFCq9Lo Link]
|Working
|Otaco
|
|}

Software projects

2009-07-02T23:52:45Z

Adventus: /* Graphic Engines */

See the [[Port Requests]] article for open-source projects which ''could'' be ported but have not been taken on by anyone yet.

== Operating Systems ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Android Omap
|[http://elinux.org/Android_on_OMAP Link]
|wip
|
|
|-
|Angstrom Linux
|[http://www.angstrom-distribution.org/ Link]
|Working build, not completed
|
|
|-
|AROS Arm
|[http://projects.powerdeveloper.org/project/imx515/735 Link]
|wip
|
|
|-
|FreeBSD
|[http://wiki.freebsd.org/FreeBSD/arm/OMAP Link]
|wip
|
|
|-
|Gentoo Linux
|[http://gentoo.openpandora.org Link]
|Working build, not completed
|javaJake, Viridior
|IRC: (FreeNode) #gentoo-pandora
|-
|HaikuOS
|[http://www.haiku-os.org Link]
|wip
|
|
|-
|Ubuntu ARM
|[http://www.ubuntu.com/products/whatisubuntu/arm Link]
|wip
|
|
|-
|Fedora ARM
|
|Unknown
|
|
|}

== Games ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|Abuse
|[http://abuse.zoy.org/ Link]
|working build
|Cpasjuste
|2D Platform
|-
|Battle for Wesnoth v1.6.2
|[http://www.gp32x.com/board/index.php?showtopic=47936 Link]
|working build
|Cpasjuste
|Strategy
|-
|BattleJewels
|
|Completed build for GP2X, WIP for Pandora
|Skeezix
|Logical
|-
|BlobWars
|[http://www.parallelrealities.co.uk/projects/blobWars.php Link]
|working build
|Cpasjuste
|2D Platform
|-
|Caster
|[http://www.gp32x.com/board/index.php?showtopic=46813 Link]
|Working build (tested on PC)
|Svartalf
|RPG
|-
|Descent 1 (d1x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|Descent 2 (d2x-rebirth engine)
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1032 Link]
|Working build
|Pickle
|FPS
|-
|FHeroes Port (Heroes Of Might And Magic 2)
|[http://www.gp32x.com/board/index.php?showtopic=47553 Link]
|Working build
|Pickle
|Strategy
|-
|FreeCiv 2.1.9
|[http://freeciv.wikia.com/wiki/Main_Page Link]
|Working build
|Cpasjuste
|Strategy
|-
|Galactic Artifact
|[http://www.gp32x.com/board/index.php?showtopic=46836 Link]
|Working build
|Trevor Bradley
|Strategy
|-
|Giannas Return
|[http://www.gianas-return.de/ Link]
|Working
|Giannas Team
|Arcade
|-
|Gravity Blocks
|[http://www.gp32x.com/board/index.php?showtopic=47662 Link]
|wip (early in developement)
|Awekening
|Arcade
|-
|Homeworld Port
|[http://www.gp32x.com/board/index.php?showtopic=47565 Link]
|wip
|LinuxHacker
|Simulation
|-
|Human Condition (was TINCS)
|[http://www.gp32x.com/board/index.php?showtopic=46487 Link1][http://www.youtube.com/user/ButtermanHimself Link2]
|wip
|Butterman
|FPP
|-
|Lerp
|[http://grapefruitopia.com/lerp/ Link]
|working build
|benjymous
|2D physics puzzle platformer
|-
|Lord of the Rings Port
|[http://www.gp32x.com/board/index.php?showtopic=46792&hl= Link]
|Unknown
|Daeglin
|RPG
|-
|Monster!
|[http://christophsdevblog.blogspot.com/ Link]
|wip
|Chris R
|Arcade
|-
|NAEV
|[http://code.google.com/p/naev/ Link]
|wip (waiting for pandora to finish and test)
|bobbens
|Action/RPG/Sim
|-
|Nails Adventure
|[http://www.gp32x.com/board/index.php?showtopic=46961 Link]
|wip
|jsmtux/Mr. Gonzo
|
|-
|OpenLiero (Liero)
|
|working build, need to be polished
|Pickle
|Shoot'Em Up
|-
|OpenTyrian
|[http://code.google.com/p/opentyrian/ Link]
|working build
|Cpasjuste
|Shoot'Em Up
|-
|Pandora Panic!
|[http://www.youtube.com/watch?v=y9d6UXhQP6o Link]
|Working build
|PokeParadox / GP32X Community
|Arcade
|-
|Pandora Pool Panic
|[http://www.gp32x.com/board/index.php?showtopic=46996 Link]
|Almost Finished
|Unfathomable Depths
|Arcade
|-
|PanMMO - Pandora MMO Game via Internet
|[http://www.youtube.com/user/enirya Link]
|wip
|Enirya
|RPG
|-
|Powermanga
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Quake 1
|
|working build
|Pickle
|FPP
|-
|Quake 2
|
|working build
|Pickle
|FPP
|-
|Quake 3
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|FPP
|-
|Quake 3
|
|working build
|Pickle
|FPP
|-
|Reminiscence (flashback)
|[http://cyxdown.free.fr/reminiscence/ Link]
|working build
|Cpasjuste
|Action/Adventure
|-
|Rise of The Triad
|[http://www.gp32x.com/board/index.php?showtopic=47931 Link]
|wip
|arrrgh
|FPP
|-
|Super Lumenal
|[http://www.youtube.com/watch?v=sZHi3YT3xuE&feature=channel_page Link]
|wip
|Adventus
|Arcade
|-
|SuperTux 1
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|SuperTux 2
|[http://forum.openhandhelds.org/viewtopic.php?f=6&t=1040 Link]
|working build
|Pickle
|Platform
|-
|Tecnoballz
|[http://mydedibox.fr/_stuff/pandora/ Link]
|Working build
|Cpasjuste
|
|-
|Teeworlds
|[http://www.teeworlds.com/ Link]
|wip
|
|Arcade
|-
|The Mana World
|[http://www.themanaworld.org/ Link]
|Working build
|Cpasjuste
|MMORPG
|-
|uHexen2: Hammer of Thyrion
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Ur-Quan Masters
|[http://www.gp32x.com/board/index.php?showtopic=43625&st=165&p=673047&#entry673047 Link]
|Working build
|
|Space Exploration
|-
|We Come In Peace
|[http://www.gp32x.com/board/index.php?showtopic=43655 Link]
|working build
|Otaco
|Strategy
|-
|Stratagus
|[http://stratagus.sourceforge.net/ Link]
|working build
|Cpasjuste
|RTS Engine
|-
|Where in world is...
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|Casual
|-
|Wizzley Presto and the Mysterious Time Machine
|[http://www.30daygame.com/ Link]
|wip
|Craigix, Zodttd, Ruckage
|Arcade, 30 Day Game Competition
|-
|Wolf4SDL (Wolfenstein 3D)
|
|working build
|Pickle
|FPP
|-
|XSwing Plus
|[http://www.gp32x.com/board/index.php?s=&showtopic=43655&view=findpost&p=733021 Link]
|wip
|Tobse
|Arcade
|-
|ZEQ2Lite
|[http://www.gp32x.com/board/index.php?showtopic=47623&hl= Link]
|Work in progress
|MDave
|Dragonball Z Third Person Fighter/Shooter
|-
|Zdoom
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|Zombd
|[http://www.gp32x.com/board/index.php?showtopic=46933 Link]
|Wip
|iprice/Mr Gonzo
|Shoot'Em Up
|}

== Emulators ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Emulated System
! Link
! Status
! Author/Port Author
! Notes
|-
|Caprice32
|Amstrad CPC
|[http://www.gp32x.com/board/index.php?showtopic=48140 Link1] [http://www.caprice32.cybercube.com/ Link2]
|wip
|hdonk
|
|-
|DosBox
|x86 DOS
|
|working build
|Pickle
|
|-
|FinalBurnAdvance
|CPS1/2/3/taito...
|[http://www.youtube.com/watch?v=06hjDLMBaf8 Link]
|
|Squidge
|
|-
|Frotz
|Z-Machine interpreter
|[http://www.cosam.org/computers/pandora/frotz-2.43.zip Link]
|
|
|
|-
|Fuse
|ZX Spectrum
|[http://www.cosam.org/computers/pandora/fuse-0.9.0.zip Link]
|working build
|SteveM
|
|-
|GnGeo
|SNK NeoGeo
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|gpSP
|Nintendo GBA
|
|wip
|ZodTTD
|
|-
|Hatari
|Atari ST
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|Jzintv
|Mattel Intellivision
|[http://www.gp32x.com/board/index.php?showtopic=48035 Link]
|
|WizardStan
|
|-
|MAME4All
|Arcade
|[http://www.youtube.com/user/franxism Link]
|
|Franxis
|
|-
|NeoPop
|SNK NeoGeo Pocket
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|NullDC
|Sega Dreamcast
|[http://www.gp32x.com/board/index.php?s=&showtopic=47065&view=findpost&p=709910 Link]
|Wip
|Zezu / drkIIraziel
|
|-
|PandaSNES
|Nintendo SNES
|[http://www.gp32x.com/board/index.php?showtopic=43213 Link]
|wip
|Squidge
|
|-
|Pandora-PSP
|Sony Playstation Portable
|[http://jayfoxrox.bplaced.net/pandora-psp/ Link]
|wip
|[[User:JayFoxRox|JayFoxRox]]
|
|-
|PAtari
|Atari 800
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PicoDrive
|Sega Genesis/CD/32x
|[http://www.youtube.com/watch?v=QDbLQI91510 Link]
|working build
|Notaz
|Fullspeed emulator
|-
|PSMS
|Sega Master System
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PSnes
|Nintendo SNES
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Psx4All
|Sony PlayStation
|[http://www.zodttd.com Link]
|Not Status, working build
|ZodTTD
|
|-
|ScummVM
|x86 Scumm engine games
|
|Working build
|DJ Willis
|Fullspeed emulator
|-
|SIMH
|old hardware
|[http://www.cosam.org/computers/pandora/simh-3.8.zip Link]
|working build
|SteveM
|
|-
|Temper
|NEC PC Engine
|[http://exophase.devzero.co.uk/ Link]
|wip
|Exophase
|Fullspeed emulator
|-
|Tempest
|Atari Jaguar
|[http://www.gp32x.com/board/index.php?showtopic=43119 Link]
|
|Firefox
|
|-
|Uae4All
|Amiga
|[http://www.gp32x.com/board/index.php?showtopic=44100 Link]
|Working build
|
|
|-
|XMAME
|Arcade
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|}

== Graphic Engines ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|GemRB (Infinity Engine)
|
|wip
|Adventus
|open-source implementation of Bioware's Infinity Engine, supports games including Baldurs Gate 2 and Planescape Torment.
|-
|GLES2D
|
|Wip
|Cpasjuste
|OpenGL ES 2D library
|-
|GL-WES-v2.0
|http://code.google.com/p/gl-wes-v2/
|Working Build
|Adventus
|Opensource OpenGL 2.0 driver built on OpenGL ES 2.0.
|-
|Irrlicht
|[http://irrlicht.sourceforge.net/] [http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=32538&start=45]
|working build
|Hybrid
|
|-
|NSS Engine
|[http://www.nosiestastudios.com/wiki/ Link1] [http://www.youtube.com/user/Prompt84 Link2]
|
|No Siesta Studios
|
|-
|OGRE Engine
|[http://www.gp32x.com/board/index.php?showtopic=46706 Link1] [http://www.youtube.com/watch?v=LDtUE5PIhV0 Link2]
|
|
|
|-
|Otaco Glost Engine
|[http://www.youtube.com/user/otacogloost Link]
|working
|Otaco
|
|-
|Quad-Ren 2D
|[http://quad-ren.sourceforge.net/index.php Link]
|
|Hessiess
|
|-
|SDL GLES
|[http://github.com/Cpasjuste/sdl-1.2.13_gles/tree Link]
|working
|Cpasjuste
|
|-
|XreaL
|[http://xreal.sourceforge.net/xrealwiki/ Link]
|
|Pickle [?]
|
|}

== Other programs ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|AbiWord - Word Processor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Claws Mail
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|Epiphany Web Bowser
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|FireFox - Internet Browser
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GIMP - Image Editor
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GMenu
|[http://www.youtube.com/watch?v=VYzi8gziC7E Link]
|Working build
|Pandora Team
|
|-
|Gnumeric Spreadsheet - Spreadsheet
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|for Angstrom OpenPandora
|-
|GoView
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Image Gallery
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Inside The Box
|[http://www.openpandora.pl Link1] [http://www.youtube.com/watch?v=uLMmJBDEs2E Link2]
|wip
|StreaK
|Pandora e-zine
|-
|IRC Client
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|LeafPad
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Matchbox Shell / GUI
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|MPlayer
|[http://www.gp32x.com/board/index.php?showtopic=41420 Link1] [http://www.youtube.com/watch?v=v9RAPNa-55k Link2]
|Working build
|Squidge
|
|-
|Pandora Sync Suite
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|for Windows 9x/NT
|-
|Pangea GUI
|[http://www.gp32x.com/board/index.php?showtopic=45631&hl=pangea Link]
|WIP
|efegea
|Gmenu alternative
|-
|PDM
|[http://github.com/Cpasjuste/pdm/tree Link]
|
|Cpasjuste
|Light desktop manager for Pandora
|-
|PGui
|[http://github.com/Cpasjuste/pgui/tree Link]
|
|Cpasjuste
|Standard emulator fronted for Pandora
|-
|Pidgin - IM (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|PMenu
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|Minimal Menu for Pandora
|-
|PND Maker (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Qemu
|[http://www.nongnu.org/qemu/status.html Link]
|testing build
|Fabrice Bellard
|open source machine emulator and virtualizer
|-
|Scale
|[http://www.youtube.com/user/Zoxc64 Link]
|wip
|Zoxc64
|Minimal Menu for Pandora
|-
|Simple Dev Studio for Pandora
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|for Windows 9x/NT
|-
|[[TINXL]]
|[[TINXL]]
|
|
|Application stack for multiplayer internet games
|-
|[[TS2A]]
|[[TS2A]]
|Documentation only
||[[User:JayFoxRox|JayFoxRox]]
|Teamspeak 2 Alternative Client / Server, Needs developer
|-
|XMMS
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|ZiB Emulator Frontend
|[http://www.gp32x.com/board/index.php?showtopic=47203 Link1] [http://www.youtube.com/watch?v=UJvON8lCM3M Link2]
|
|Aimless_E
|
|}

== Demos / Technical Demos for OpenPandora ==
{|class="wikitable sortable" border="1" cellpadding="1" cellspacing="0" style="font-size: 90%; border:1px solid gray; border-collapse: collapse; text-align: center; width: 100%;"
|- style="background: #ececec"
! Project Name
! Link
! Status
! Author/Port Author
! Notes
|-
|OpenGL Cell Shading
|[http://www.youtube.com/watch?v=cpAj0jHglGw Link]
|working build
|
|
|-
|OpenGL Demo with MP3 Playback
|[http://www.youtube.com/watch?v=hkx18kruRJs Link]
|working build
|
|
|-
|OpenGL Skull Demo
|[http://www.youtube.com/watch?v=qG7EDaZpyOo Link]
|working build
|
|
|-
|WaveDemo
|[http://www.youtube.com/watch?v=4wgEHFCq9Lo Link]
|Working
|Otaco
|
|}

Software projects

2009-04-25T01:04:19Z

Adventus: /* Games */

== Operating Systems ==
{|class="wikitable sortable" border="1" cellspacing="0" cellpadding="2" style=";border: 1px solid;text-align:center;" width=100%
! style="background:#E9E9E9;border: 1px #111111 solid;" |Project Name
! style="background:#E9E9E9;border: 1px #111111 solid;" |Link
! style="background:#E9E9E9;border: 1px #111111 solid;" |Status
! style="background:#E9E9E9;border: 1px #111111 solid;" |Author/Port Author
! style="background:#E9E9E9;border: 1px #111111 solid;" |Notes
|-
|Angstrom Linux
|[http://www.angstrom-distribution.org/ Link]
|Working build, not completed
|
|
|-
|HaikuOS
|[http://www.haiku-os.org Link]
|wip
|
|
|-
|Gentoo Linux
|[http://gentoo.openpandora.org Link]
|Working build, not completed
|
|
|-
|Ubuntu ARM
|
|Unknown
|
|
|-
|AROS Arm
|[http://projects.powerdeveloper.org/project/imx515/735 Link]
|wip
|
|
|-
|FreeBSD
|[http://wiki.freebsd.org/FreeBSD/arm/OMAP Link]
|wip
|
|
|-
|Android Omap
|[http://elinux.org/Android_on_OMAP Link]
|wip
|
|
|}

== Games ==
{|class="wikitable sortable" border="1" cellspacing="0" cellpadding="2" style=";border: 1px solid;text-align:center;" width=100%
! style="background:#E9E9E9;border: 1px #111111 solid;" |Project Name
! style="background:#E9E9E9;border: 1px #111111 solid;" |Link
! style="background:#E9E9E9;border: 1px #111111 solid;" |Status
! style="background:#E9E9E9;border: 1px #111111 solid;" |Author/Port Author
! style="background:#E9E9E9;border: 1px #111111 solid;" |Notes
|-
|FHeroes Port (Heroes Of Might And Magic 2)
|
|Working build
|Pickle
|RPG
|-
|OpenLiero (Liero)
|
|working build, need to be polished
|Pickle
|Shoot'Em Up
|-
|Quake 2
|
|working build
|
|FPP
|-
|Homeworld Port
|[http://www.gp32x.com/board/index.php?showtopic=47565 Link]
|wip
|LinuxHacker
|Simulation
|-
|Pandora Panic!
|[http://www.youtube.com/watch?v=y9d6UXhQP6o Link]
|Working build
|PokeParadox / GP32X Community
|Arcade
|-
|TINCS
|[http://www.youtube.com/user/ButtermanHimself Link]
|wip
|Butterman
|FPP
|-
|Where in world is...
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|Casual
|-
|Galactic Artifact
|[http://www.gp32x.com/board/index.php?showtopic=46836 Link]
|Working build
|Trevor Bradley
|Strategy
|-
|Nails Adventure
|[http://www.gp32x.com/board/index.php?showtopic=46961 Link]
|wip
|jsmtux/Mr. Gonzo
|
|-
|Tecnoballz
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Powermanga
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Battle for Wesnoth
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|Strategy
|-
|Quake 3
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|FPP
|-
|Zombd
|
|Wip
|iprice/Mr Gonzo
|Shoot'Em Up
|-
|Wolf4SDL (Wolfenstein 3D)
|
|working build
|Pickle
|FPP
|-
|PrBoom (Doom)
|
|working build
|Pickle
|FPP
|-
|Quake 1
|
|working build
|Pickle
|FPP
|-
|Quake 3
|
|working build
|Pickle
|FPP
|-
|Wizzley Presto
|[http://www.30daygame.com/ Link]
|wip
|Craigix, Zodttd, Ruckage
|Arcade, 30 Day Game Competition
|-
|We Come In Peace
|[http://www.gp32x.com/board/index.php?showtopic=43655 Link]
|working build
|Otaco
|Strategy
|-
|Lerp
|[http://grapefruitopia.com/lerp/ Link]
|working build
|
|Arcade
|-
|Pandora Pool Panic
|[http://www.gp32x.com/board/index.php?showtopic=46996 Link]
|Almost Finished
|Unfathomable Depths
|Arcade
|-
|Caster
|[http://www.gp32x.com/board/index.php?showtopic=46813 Link]
|
|
|RPG
|-
|Lord Of The Rings Port
|[http://www.gp32x.com/board/index.php?showtopic=46792&hl= Link]
|Unknown
|Daeglin
|RPG
|-
|Teeworlds
|[http://www.teeworlds.com/ Link]
|wip
|
|Arcade
|-
|zeg2Lite
|[http://www.gp32x.com/board/index.php?showtopic=47623&hl= Link]
|wip
|MDave
|FPP
|-
|Monster!
|[http://christophsdevblog.blogspot.com/ Link]
|wip
|Chris R
|Arcade
|-
|PanMMO - Pandora MMO Game via Internet
|[http://www.youtube.com/user/enirya Link]
|wip
|Enirya
|RPG
|-
|Super Lumenal
|[http://www.youtube.com/watch?v=sZHi3YT3xuE&feature=channel_page Link]
|wip
|Adventus
|Arcade
|-
|Zdoom
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|uHexen2: Hammer of Thyrion
|
|Completed build for GP2X, WIP for Pandora
|Adventus
|FPP
|-
|GemRB (Infinity Engine)
|
|wip
|Adventus
|RPG
|-
|BattleJewels
|
|Completed build for GP2X, WIP for Pandora
|Skeezix
|Logical
|-
|Giannas Return
|[http://www.gianas-return.de/ Link]
|Working
|Giannas Team
|Arcade
|-
|Ur-Quan Masters
|[http://www.gp32x.com/board/index.php?showtopic=43625&st=165&p=673047&#entry673047 Link]
|Working build
|
|Strategy
|}

== Emulators ==
{|class="wikitable sortable" border="1" cellspacing="0" cellpadding="2" style=";border: 1px solid;text-align:center;" width=100%
! style="background:#E9E9E9;border: 1px #111111 solid;" |Project Name
! style="background:#E9E9E9;border: 1px #111111 solid;" |Link
! style="background:#E9E9E9;border: 1px #111111 solid;" |Status
! style="background:#E9E9E9;border: 1px #111111 solid;" |Author/Port Author
! style="background:#E9E9E9;border: 1px #111111 solid;" |Notes
|-
|Psx4All (Sony Playstation emulator)
|[http://www.zodttd.com Link]
|Not Status, working build
|ZodTTD
|
|-
|PicoDrive (Sega Genesis emulator)
|[http://www.youtube.com/watch?v=QDbLQI91510 Link]
|working build
|Notaz
|Fullspeed emulator
|-
|PSnes (Nintendo SNES]
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PAtari (Atari 800)
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|PSMS (Sega MasterSystem)
|[http://mydedibox.fr/_stuff/pandora/ Link]
|working build
|Cpasjuste
|
|-
|Pandora-PSP (Sony Playstation Portable)
|[http://jayfoxrox.bplaced.net/pandora-psp/ Link]
|wip
|JayFoxRox
|
|-
|Tempest (Atari Jaguar)
|
|
|
|
|-
|Temper (PC Engine)
|[http://exophase.devzero.co.uk/ Link]
|wip
|Exophase
|Fullspeed emulator
|-
|MAME4All (MAME)
|[http://www.youtube.com/user/franxism Link]
|
|Franxis
|
|-
|FinalBurnAdvance (CPS1/2/3/taito...)
|[http://www.youtube.com/watch?v=06hjDLMBaf8 Link]
|
|Squidge
|
|-
|The Frotz Z-Machine (Zork interpreter)
|[http://www.cosam.org/computers/pandora/frotz-2.43.zip Link]
|
|
|
|-
|Fuse (ZX Spectrum)
|[http://www.cosam.org/computers/pandora/fuse-0.9.0.zip Link]
|working build
|SteveM
|
|-
|ScummVM (Scumm games)
|
|Working build
|DJ Willis
|Fullspeed emulator
|-
|Simh (emulate old hardware)
|[http://www.cosam.org/computers/pandora/simh-3.8.zip Link]
|working build
|SteveM
|
|-
|GnGeo (NeoGeo)
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|NeoPop (Neogeo Pocket)
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|Hatari (Atari ST)
|[http://mydedibox.fr/_stuff/pandora/ Link1] [http://www.youtube.com/user/cpasjuste Link2]
|
|Cpasjuste
|
|-
|XMAME (MAME)
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|-
|DosBox
|
|working build
|Pickle
|
|-
|NullDC (Sega Dreamcast)
|[http://www.gp32x.com/board/index.php?s=&showtopic=47065&view=findpost&p=709910 Link]
|Wip
|Zezu / drkIIraziel
|
|-
|Uae4All (Amiga)
|[http://www.gp32x.com/board/index.php?showtopic=44100 Link]
|Working build
|
|
|-
|PandaSNES (Super Nintendo)
|[http://www.gp32x.com/board/index.php?showtopic=43213 Link]
|wip
|Squidge
|
|-
|gpSP (Game Boy Advance)
|
|wip
|ZodTTD
|
|}

== Graphic Engines ==
{|class="wikitable sortable" border="1" cellspacing="0" cellpadding="2" style=";border: 1px solid;text-align:center;" width=100%
! style="background:#E9E9E9;border: 1px #111111 solid;" |Project Name
! style="background:#E9E9E9;border: 1px #111111 solid;" |Link
! style="background:#E9E9E9;border: 1px #111111 solid;" |Status
! style="background:#E9E9E9;border: 1px #111111 solid;" |Author/Port Author
! style="background:#E9E9E9;border: 1px #111111 solid;" |Notes
|-
|NSS Engine
|[http://www.nosiestastudios.com/wiki/ Link1] [http://www.youtube.com/user/Prompt84 Link2]
|
|No Siesta Studios
|
|-
|XreaL
|[http://xreal.sourceforge.net/xrealwiki/ Link]
|
|Pickle [?]
|
|-
|Quad-Ren 2D
|[http://quad-ren.sourceforge.net/index.php Link]
|
|Hessiess
|
|-
|OGRE Engine
|[http://www.gp32x.com/board/index.php?showtopic=46706 Link1] [http://www.youtube.com/watch?v=LDtUE5PIhV0 Link2]
|
|
|
|-
|SDL GLES
|[http://github.com/Cpasjuste/sdl-1.2.13_gles/tree Link]
|working
|Cpasjuste
|
|-
|Otaco Glost Engine
|[http://www.youtube.com/user/otacogloost Link]
|working
|Otaco
|
|}

== Other programs ==
{|class="wikitable sortable" border="1" cellspacing="0" cellpadding="2" style=";border: 1px solid;text-align:center;" width=100%
! style="background:#E9E9E9;border: 1px #111111 solid;" |Project Name
! style="background:#E9E9E9;border: 1px #111111 solid;" |Link
! style="background:#E9E9E9;border: 1px #111111 solid;" |Status
! style="background:#E9E9E9;border: 1px #111111 solid;" |Author/Port Author
! style="background:#E9E9E9;border: 1px #111111 solid;" |Notes
|-
|ZiB Emulator Frontend
|[http://www.gp32x.com/board/index.php?showtopic=47203 Link1] [http://www.youtube.com/watch?v=UJvON8lCM3M Link2]
|
|Aimless_E
|
|-
|PND Maker (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Pandora Sync Suite (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Working build
|StreaK
|
|-
|Inside The Box (Pandora e-zine)
|[http://www.openpandora.pl Link1] [http://www.youtube.com/watch?v=uLMmJBDEs2E Link2]
|wip
|StreaK
|
|-
|PMenu (Minimal Menu for Pandora)
|[http://mydedibox.fr/_stuff/pandora/ Link]
|
|Cpasjuste
|
|-
|Simple Dev Studio for Pandora (for Windows 9x/NT)
|[http://www.openpandora.pl Link]
|Wip
|StreaK
|
|-
|Qemu - open source machine emulator and virtualizer
|[http://www.nongnu.org/qemu/status.html Link]
|testing build
|Fabrice Bellard
|
|-
|TINXL - Application stack for multiplayer internet games
|[[TINXL]]
|
|
|
|-
|PGui - Standard emulator fronted for the pandora gaming console
|[http://github.com/Cpasjuste/pgui/tree Link]
|
|Cpasjuste
|
|-
|PDM - A light desktop manager for the pandora gaming console
|[http://github.com/Cpasjuste/pdm/tree Link]
|
|Cpasjuste
|
|-
|Scale - Minimal Menu for Pandora
|[http://www.youtube.com/user/Zoxc64 Link]
|wip
|Zoxc64
|
|-
|FireFox - Internet Browser (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|GIMP - Image Editor (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|Claws Mail (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|AbiWord - Word Processor (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|Pidgin - IM (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|Gnumeric Spreadsheet - Spreadsheet (for Angstrom OpenPandora)
|[http://www.youtube.com/watch?v=oYf-I1UuWhk Link]
|working build
|
|
|-
|Matchbox Shell / GUI
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|MPlayer
|[http://www.gp32x.com/board/index.php?showtopic=41420 Link1] [http://www.youtube.com/watch?v=v9RAPNa-55k Link2]
|Working build
|Squidge
|
|-
|Epiphany Web Bowser
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|LeafPad
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|Image Gallery
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|GoView
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|IRC Client
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|XMMS
|[http://www.youtube.com/watch?v=sKKMj37Psd8 Link]
|Working build
|
|
|-
|GMenu
|[http://www.youtube.com/watch?v=VYzi8gziC7E Link]
|Working build
|Pandora Team
|
|}

== Demos / Technical Demos for OpenPandora ==
{|class="wikitable sortable" border="1" cellspacing="0" cellpadding="2" style=";border: 1px solid;text-align:center;" width=100%
! style="background:#E9E9E9;border: 1px #111111 solid;" |Project Name
! style="background:#E9E9E9;border: 1px #111111 solid;" |Link
! style="background:#E9E9E9;border: 1px #111111 solid;" |Status
! style="background:#E9E9E9;border: 1px #111111 solid;" |Author/Port Author
! style="background:#E9E9E9;border: 1px #111111 solid;" |Notes
|-
|WaveDemo
|[http://www.youtube.com/watch?v=4wgEHFCq9Lo Link]
|Working
|Otaco
|
|-
|OpenGL Skull Demo
|[http://www.youtube.com/watch?v=qG7EDaZpyOo Link]
|working build
|
|
|-
|OpenGL Cell Shading
|[http://www.youtube.com/watch?v=cpAj0jHglGw Link]
|working build
|
|
|-
|OpenGL Demo with MP3 Playback
|[http://www.youtube.com/watch?v=hkx18kruRJs Link]
|working build
|
|
|}