[M3devel] Bare Metal Modula-3

[Darko]

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>