[M3devel] Bare Metal Modula-3

Darko darko at darko.org
Fri Jan 4 21:07:43 CET 2013


The threading, GC and TCP/IP are required by my software, so they have to be implemented, the question is what is the minimum required to implement them. No other OS services are required, and no OS would be installed. Some external libraries would be required, like a TCP/IP stack, but those are available without OS dependencies.

The target system is the Samsung Exynos 4 Quad SoC. It has a 4 ARM Cortex-A9 cores running at 1.6GHz and 2GB integrated DRAM.

Added to that would be a gigabit ethernet port. The whole system would have a maximum power draw of something like 5W.

The manual can be found here for those interested: 

http://www.samsung.com/global/business/semiconductor/file/product/Exynos_4_Quad_User_Manaul_Public_REV100-0.pdf


The idea is to build a low cost, low power computing node that can deployed in large numbers. It would only run one threaded application and all I/O would be through the network port, so the OS would do little else than create overhead.

So far, aside from hardware initialization, I know I'd have to write a timer interrupt for user threads, some code to assign threads to cores, and an implementation of mmap/munmap, but I imagine not a full one since from what I understand only some of the functionality is used to catch access to various parts of memory.

I know I'd have to remove the many parts of m3core, libm3 and other libraries that reference OS services.



On Jan 4, 2013, at 9:08 AM, Jay K wrote:

> What is the system?
> 
> 
> 
> It is possible to not need memory allocation or threading or garbage collection.
> You could use just globals and/or locals.
> 
> 
> 
> It is possibe to not need garbage collection.
> Use unsafe and new/dispose for dynamic allocation.
> The garbage collector for example, doesn't need garbage collection.
> 
> 
> 
> It is possible to not need threads.
> It is obvious how.
> But be aware that "libraries", including the garbage collector, create threads.
> 
> 
> 
> Anyway, "yes".
> There are currently three usermode thread implementations.
>  1) "get/set/make/swapcontext" 
>  2) "sigaltstack" 
>  3) "setjmp/timers" 
>   This looks currently unused, and maybe deleted.
> 
> 
> 
> I guess they all user timers.
> 
> 
> 
> To start, see:
> 
>   
>   jbook2:src jay$ pwd
>   /dev2/cm3/m3-libs/m3core/src
> 
>   
>   jbook2:src jay$ find . | grep c$ | grep -i thread
>   ./thread/POSIX/ThreadPosixC.c
>   OR
>   ./thread/PTHREAD/ThreadPThreadC.c
> 
> 
> 
> Really, providing pthreads wouldn't be a bad idea.
> 
> 
> 
> For memory allocation, we use at least calloc, free, maybe malloc,
> and mmap/munmap. You could probably replace mmap/munmap with calloc/malloc/free.
> 
> 
> 
> If you really want to link all of m3core and libm3, you'll
> need more, open/close/read/write, fork or vfork/exec.
> 
> 
> 
> The way to know is probably just to try it.
> Do you have a working C compiler/libraries/headers?
> Can you just try it?
> 
> 
> nm against cm3 is probably useful.
> Some of these might be injected by "startup" code.
> Some are wrappers for other code to use -- might not be used.
> Some are implementation details of the C library.
> 
> 
>  nm /cm3/bin/cm3 | grep " U "  
> 
> 
>                  U ___error
>                  U ___gxx_personality_v0
>                  U ___sF
>                  U ___stderrp
>                  U __exit
>                  U __longjmp
>                  U __setjmp
>                  U _abort
>                  U _access
>                  U _calloc
>                  U _ceil
>                  U _chdir
>                  U _close
>                  U _closedir
>                  U _dup2
>                  U _execve
>                  U _execvp
>                  U _exit
>                  U _fcntl
>                  U _feclearexcept
>                  U _fegetround
>                  U _feraiseexcept
>                  U _fesetround
>                  U _fetestexcept
>                  U _fflush
>                  U _floor
>                  U _fork
>                  U _fprintf
>                  U _free
>                  U _fstat
>                  U _fsync
>                  U _fwrite
>                  U _getcwd
>                  U _getdtablesize
>                  U _getegid
>                  U _getenv
>                  U _geteuid
>                  U _gethostname
>                  U _getpid
>                  U _gettimeofday
>                  U _gmtime
>                  U _kill
>                  U _ldexp
>                  U _link
>                  U _llroundl
>                  U _localtime
>                  U _lseek
>                  U _lstat
>                  U _malloc
>                  U _memcmp
>                  U _memmove
>                  U _memset
>                  U _mkdir
>                  U _mktime
>                  U _mmap
>                  U _modf
>                  U _nanosleep
>                  U _open
>                  U _opendir
>                  U _pipe
>                  U _poll
>                  U _pthread_atfork
>                  U _pthread_attr_destroy
>                  U _pthread_attr_getstacksize
>                  U _pthread_attr_init
>                  U _pthread_attr_setstacksize
>                  U _pthread_cond_broadcast
>                  U _pthread_cond_destroy
>                  U _pthread_cond_init
>                  U _pthread_cond_signal
>                  U _pthread_cond_timedwait
>                  U _pthread_cond_wait
>                  U _pthread_create
>                  U _pthread_detach
>                  U _pthread_equal
>                  U _pthread_getspecific
>                  U _pthread_key_create
>                  U _pthread_kill
>                  U _pthread_mach_thread_np
>                  U _pthread_mutex_destroy
>                  U _pthread_mutex_init
>                  U _pthread_mutex_lock
>                  U _pthread_mutex_unlock
>                  U _pthread_self
>                  U _pthread_setspecific
>                  U _read
>                  U _readdir
>                  U _readlink
>                  U _rename
>                  U _rmdir
>                  U _sched_yield
>                  U _sigaction
>                  U _sigsetjmp
>                  U _sleep
>                  U _stat
>                  U _strcmp
>                  U _strtod
>                  U _symlink
>                  U _thread_abort_safely
>                  U _thread_get_state
>                  U _thread_resume
>                  U _thread_suspend
>                  U _time
>                  U _tzset
>                  U _uname
>                  U _unlink
>                  U _utimes
>                  U _waitpid
>                  U _write
> 
> 
> 
>  - Jay
> 
> 
> 
> 
> > From: darko at darko.org
> > Date: Fri, 4 Jan 2013 01:16:47 -0800
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] Bare Metal Modula-3
> > 
> > I'm interested in deploying M3 into a kind-of embedded environment where efficiency and performance are key and I want to avoid installing an OS beyond a simple supervisor that manages the hardware. 
> > 
> > The services needed are threading, memory allocation and network access. I'm figuring the first two already exist in M3 and a network stack can be found.
> > 
> > The question I have is can all of the OS specific runtime can be removed? Beyond maybe a timer and possibly some memory protection functionality, what does M3 need to run threading and garbage collection?
> > 
> > - Darko
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130104/2abe7d8c/attachment-0002.html>


More information about the M3devel mailing list