[M3devel] Bare Metal Modula-3

Sat Jan 5 19:15:20 CET 2013

Hi all:
the core services as here explained must be maintained CPU and memory management regardless of any other tasks, I don't think even Gnu/Linux is capable of doing this today:
http://www.poppyfields.net/acorn/news/acopress/97-02-10b.shtml

Core services independent of platform are the top part to maintain available during updates over network, interesting service.

 I would use their RT rather than CM3, which is nice but not for embedded OS kernel, certainly.
Never released guess why?
Thanks in advance

--- El sáb, 5/1/13, Darko <darko at darko.org> escribió:

De: Darko <darko at darko.org>
Asunto: Re: [M3devel] Bare Metal Modula-3
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: sábado, 5 de enero, 2013 03:24

That shouldn't be hard, there's a detailed guide here using GCC:
http://www.state-machine.com/arm/Building_bare-metal_ARM_with_GNU.pdf
Building an ARM cross compiler will be a bit more involved and although there don't seem to be any fundamental dependencies in the runtime I get the feeling separating the M3 minimalist portion from the OS dependent portion is going to be messy. 

On Jan 4, 2013, at 6:40 PM, Jay K wrote:
Get hello world running on your system first, written in C. Then get back to us. :)
Seriously.

Ok, maybe not with stdio.
At least this:

int main()
{
 malloc(1);
 return 0;
}

 - Jay

Subject: Re: [M3devel] Bare Metal Modula-3
From: darko at darko.org
Date: Fri, 4 Jan 2013 16:45:27 -0800
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

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/20130105/14ad2504/attachment-0002.html>