[M3devel] Bare Metal Modula-3

Darko darko at darko.org
Sat Jan 5 01:45:27 CET 2013


That's useful to know. It makes implementing memory allocation very straight forward. All I'd need to implement would be some calls for setting aside pages of memory and setting their read/write status, which would be directly supported by the hardware.

It also occurs to me I'd have to write some sort of loader, which shouldn't be difficult as long as I can link the m3 program into some sort of monolithic "raw" format that I can just copy into a fixed place in memory and start executing.



On Jan 4, 2013, at 4:36 PM, Jay K wrote:

> Clarification regarding mmap.
>  
>  
> mmap has two fairly different purposes in Posix.
>  
>  
>  1) to "map a file" into memory 
>  2) to "allocate memory", probably with address and size page-aligned, probably for relatively large allocations (i.e. ones you don't mind rounding up to a page size).  
>  
>   #1 is the more obvious probably better known use. The one I knew of. The one it sounds like. 
>   #2 is what we use it for.  
>  
>  
> If we ever autoconf-m3core, it'd probably be reasonable to do something like:
>  
>  
> #if HAS_MMAP
> return mmap(...);
>  
> #elif HAS_CALLOC
>  
> void** p = (void**)calloc(size + sizeof(void*));
> if (!p) return p;
> p[0] = p;
> return p + 1;
>  
> #else
> #error
> #endif
>  
>  
> #if HAS_MMAP
> munmap(...);
>  
> #elif HAS_CALLOC
>  
> if (p)
>   free(((void**)p)[-1]);
>  
> #endif
>  
>  
> alternatively though, look for every directory named "POSIX" and make a copy of it, and modify as needed.
> Including assert(0) in places.
> Invent your own value for "OS_TYPE".
>  
>  
> Maybe
>  #define OS_TYPE_FOO 
>  #include ../POSIX/Foo.c 
>  
> and #ifndef OS_TYPE_FOO in Foo.c, if it isn't too messy.
>  
>  
> Sharing code can be good or bad.
>  
>  
> We don't actually use "memory protection".
> Er, well..maybe we do...we might have code that allocates stacks, and makes a page at either end inaccessible.
> This is nice. It might be required for "safety".
> It might also be a good idea to have a flag in Target.i3 that says the target needs calls in prologues to check for stack overflow, and use that instead.
> More portable -- i.e. doesn't require hardware page protection -- but bigger/bloated/slower.
>  
>  
>  
> Really you need to look at all the POSIX/PTHREAD/WIN32 directories, esp. in m3core and libm3.
> You make a much different system, you get to do the port.
> It is neither impossible nor a no-op.
>  
>  
>  - Jay
> 
> 
> 
> 
>  
> From: darko at darko.org
> Date: Fri, 4 Jan 2013 12:09:26 -0800
> To: dabenavidesd at yahoo.es
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Bare Metal Modula-3
> 
> It's not a realtime system, so that's not a problem. Have a look at my reply to Jay you'll see a fuller description of what I have in mind.
> 
> 
> On Jan 4, 2013, at 10:46 AM, Daniel Alejandro Benavides D. wrote:
> 
> Hi all:
> I think you just need runtime executive on top a machine would be enough.
> For instance VAXELN. 
> Problem is you would need realtime core services at the language level (somehow SPIN services with no protection overhead caused by language).
> Memory managament.  and threading are core services in VAXELN as part of system, just need bindings for each language.
> I guess you need and advanced distributed realtime system. Such was VMS 5 for rtVAX9000:
> http://books.google.com.co/books?id=TzUXAQAAMAAJ&dq="%2C+in+conjunction+with+VMS.+VAXELN%2C+which+provides+optimal+performance+for"&q="+which+provides+optimal+performance+for"#search_anchor
> 
> My hypothesis is that you can't bring up a realtime application in an embedded device like you want.
> I know of realtime OS in Modula-3, there must be several ones I guess, based on what I have researched but you can not trust whether they are embedded, that's the problem.
> Thanks in advance
> 
> 
> --- El vie, 4/1/13, Darko <darko at darko.org> escribió:
> 
> De: Darko <darko at darko.org>
> Asunto: [M3devel] Bare Metal Modula-3
> Para: "m3devel developers" <m3devel at elegosoft.com>
> Fecha: viernes, 4 de enero, 2013 04:16
> 
> 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/86cdc675/attachment-0001.html>


More information about the M3devel mailing list