>-----Original Message----- >From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev- >boun...@uclinux.org] On Behalf Of Jamie Lokier >Sent: Tuesday, April 13, 2010 5:36 AM >To: uClinux development list >Subject: Re: [uClinux-dev] Creating a new arch > >Lennart Sorensen wrote: >> How can software protect you from bad pointers clobbering memory from >> some other process? Sure the language/compiler can runtime check >every >> pointer before using it. Sounds very inefficient though. > >It's called static analysis or type checking. The compiler proves >that there are no bad pointers as much as possible, so it doesn't have >to check them at run time. If there are any remaining ones, it can >check them. Depending on the language and type of program, it is >sometimes possible to prove there are no bad pointers and nothing has >to be done when the program is running. Correct .
Note no compiled binaries will be allows so no user written c or C++. We provide a CIL -> Arch compiler ( or Mono does) . The user will put a Java , Java script or CIL ( .NET) app and the trusted compiler will compile the binary and place it in a special location. CIL can be compile time checked with ease , java and Java script are supported via Java to CIL converter . It provides the major benefits of no Arch related user code apps will run on any arch ( except for capability limitations such a 3D ) , and compiles are optimized for the platform ( ala Gentoo without the emerge pain). The price is no c or C++ , initially I will include some precompiled C and C++ ( from the usLinux libs) and it provides us a great leap to get a working OS from writing everything in C# . The only system C# apps we had so far were rudimentary FAT and ext2 drivers. > >> There are things that are trivial to do in hardware and very hard (or >> at least very expensive) to do in software. Memory protection is one >> of those things. > >Having used both no-MMU architectures and MMU architectures, I >_strongly_ recommend having a decent MMU. > >It is not just memory protection (you can get that with an MPU). > >It's the ability to avoid memory fragmentation, which is a serious >problem with no-MMU architectures running Linux - at least if you >often spawn processes and things like that. > >Fragmentation is a much bigger problem than I would have expected when >I first started doing uClinux. > >Then again, if you're using type-safe languages or run-times designed >for the purpose, fragmentation needn't be an issue either. Correct using a compacting GC for Java , oCaml and C#. ( Which also makes the checking easy since there are no pointers). Also this frag is partially due to no MMU hw having little memory larger devices are more likely to have an MMU , it is less of an issue on a 4G machine. Regards, Ben _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
