Then a lot of friend tell me that the future will be firefox os .
It may call a 5 years university course but ... what is the way to have a dsl similar os running on epiphany?
The news on this post are quite old, is there already something to try (like an sd image unstable but barely usable) ?
I'm not a coder and i'm quite hard on understanding git and similar software instruments but is there any way i can help you on this task?
Thanks for your work.
Hope to see something relatively soon
Statistics: Posted by adexmont — Mon Sep 01, 2014 11:34 am
]]>
]]>
- OS4E : Yes it is. She is going to run on Epiphany.
- loader : Yes, I have to write a loader/starter - a little angel - which is prepare the all stuff around and inside Epiphany and then say : breathe!
- ARM side : (Better to say Zynq or more precisely PS+PL) : Well, the 'angel' must load the 'E-code' - as You wrote - and reprogram the PL (Programmable Logic) . 'As I guess' : for the proper 'external' memory handling we need a 'modded' PL : MMU+DMA?! ... anyway You are right, this is an another ARCH, so toolchain. One more trick: I wondering about the same OS code base for ARM and Epiphany. - I like to keep alive 'ARM PS (Processing System)' after the 'angel' finish her jobs.
- For Your questions: (1) ... or am I misunderstanding your intentions? : You got it. (2) Are you building both sides from scratch, or are you planning on using the provided Linux distribution to load your OS? Well, as I see the provided GNU/Linux is too heavy, I have built an another GNU/Linux yet. . BUT(!) I really wondering to start OS trials on ARM. ...
- Your OS : Very nice approaching. Good luck for it(!) Let we see Your code too(!) Regards, Gabor.
Statistics: Posted by mrgs — Fri Mar 08, 2013 10:04 am
]]>
]]>
- compilers : Please let me use just the 'compiler' word. From my point of view (or based on my understanding), I am going to use the 'lower lever part of the Epiphany SDK' - compiler / assembler / bin utils ... which is capable to compile my pure C / assembly codes into 'machine code' /binary code. "I assume" the compiler does not know : is this an OS or an application or a library?! .
- misunderstanding : Well, maybe my poor English or poor knowledge occurs some non-clear situation. I beg Your pardon.
- SUMMARIZE: 'My' simple OS should work on the Epiphany with a 'little' HW support.
Regards, Gabor. Have a nice day!Statistics: Posted by mrgs — Thu Mar 07, 2013 8:15 am
]]>
The reason for building a bootstrap compiler is to allow you to write the kernel and kernel libs that provide that code. Using the provided compiler wouldn't work because it is built for a specific OS, not the one you are writing.
I don't mean to be contentious; I am just trying to understand. Am I misunderstanding something about the provided toolchain or your design?
Statistics: Posted by SamJBarney — Wed Mar 06, 2013 4:07 pm
]]>
- "ARM managed approaches" : Where the ARM CPU is the master and the E16 cores are slaves. A kind of co-processor approaches. - In my "vision" the E16G301 will be the main, "stand alone" CPU/mesh with own OS.
Regards, GaborStatistics: Posted by mrgs — Wed Mar 06, 2013 3:22 pm
]]>
Statistics: Posted by SamJBarney — Wed Mar 06, 2013 2:13 pm
]]>
Statistics: Posted by mrgs — Wed Mar 06, 2013 9:09 am
]]>
As for the soft MMU concept, I do not know how well that will work, but I will spend some time mulling it over before I make a full comment on it.
My concept of how to implement multi-threading is built around using one of the ARM cores as a thread/process scheduler. Any thoughts?
Statistics: Posted by SamJBarney — Tue Mar 05, 2013 7:32 pm
]]>
“... I realized the problem is not the language but what ideas the language has implemented. ...” : I agree.
“... . it's only the libs that matter, the os and the services it provides … “ : On a proper level of abstraction with 'a precise knowledge' how far this level (libs, OS) from the real processing system.
Parallella vs Epiphany : You are right, actually we have to support Epiphany with a 'little' additional hardware. But a question arise: Does Epiphany start to work (boot) at 'classical' native mode. I think, she does not. We need an 'external agent' (better to call a 'little angel') to 'boot Epiphany'. So, some external HW MMU is just for fun. I would not like to emulate another system I 'just' like to bring out the best from the 'current' ARCH. (Parallella)
'POISIX - compatible' and compile-time runtime 2. : POSIX is not a 'must have' stuff, It 'just' show a standard way of an OS, so, I am not sure at now. Back to the compile-time vs runtime again: As You mentioned the two endpoint: The answer is: to find the right balance(!), well, IMHO a 'little' more 'force' should to go to the runtime.
Cores / 'S'RAM : Well, it is a hard question. Will I more happy with more RAM inside on the chip?! What a crazy question?! Of course Yes, … OR NOT(!) I guess, I could be more happy with a 'light' MMU, and native, stand alone starting. But these do not matter in really. I think, 'our major measure is GFOPS/W' now.
'OS for 16-core Epiphany' : Yes, 'why' not?! I am going to use 'only 2 local memory banks permanently' for OS4E. (!) It does not mean that the size of OS is 16K.
"...even though my suggestion sounds a bit like a scripting-language, it needs to be done by an os and not by a compiler alone, it is far away from being an actual abstraction, and requires run-time info..." : I think, this is a good 'join point' : OS will deliver nice run-time info ...
SUMMARIZE : Later or soon I have to show something. I think the best way, which is really represents my ideas, is some source code. 'Let me go!'
Regards, GaborStatistics: Posted by mrgs — Thu Feb 07, 2013 9:49 pm
]]>
as for the ideal programming language, once upon a time I too thought there would be a programming-language for every purpose, each having an own character and whoever wants something that isn't a language could just create one. but then I realized the problem is not the language but what ideas the language has implemented. for example I like the idea of static oop, therefore I hate java and love c++. and the reason I like the idea of static oop is that it allows to implement even newer ideas for what a language could do, without slowing down run-time. choosing a language really isn't about personal preferences, it's about choosing the newest technology one has deemed useful. that's why programming language does not matter, with the right preprocessor even assembler could become the right platform-independent language. it's only the libs that matter, the os and the services it provides
what you are talking about is an os for parallella, an os for epiphany should run the epiphany cores in a native mode, allowing to make use of what already is present, and it shouldn't try to emulate some other kind of system. there's lots of libs to choose from for a posix-compatible os, so I can understand you want os4e to be posix-compatible including posix threads. however, I think since all those useful libs have nice source-code, it does not make sense to solve everything at run-time, and the other way around it neither makes sense to rely on the programmers to take care of threading as opposed to handling that during runtime where it is known what threads the other cores are occupied with. we complain how little 32k is, but on a truely multicore epiphany of the future, 4k cores with a total of 128mb on-chip memory, there'll be plenty of space for an os, but no user-friendly application with current threading technology will ever manage to keep all these cores occupied!imho 16-core epiphany does not need an os, but once the chip has more cores than your programs have manually prepared threads in the sourcecode, then some os would be needed to actually create many more threads! as I said, imho abstraction is the only thing an os shouldn't do because it better fits a programming-language. even though my suggestion sounds a bit like a scripting-language, it needs to be done by an os and not by a compiler alone, it is far away from being an actual abstraction, and requires run-time info...
Statistics: Posted by piotr5 — Thu Feb 07, 2013 10:56 am
]]>
]]>
]]>
topic : As 'language v.s. OS' : Well, first of all, I think, this is not a fight, this is a cooperation between the OS and 'the language'. With the separation of 'this two phenomena' I would like to partition the 'problems'/tasks.
ideal language : Well, tell the true I do not understand Your idea about the 'ideal language'. But(!) Let me note: In my model, the language is 'just' a tool to describe 'something'. An 'ideal language' is 'nice' / 'expressive' / 'natural' / 'consistent' / ... 'human lovable'
'better handled by language' : Well, I think we are free as special at the abstractions. A 'poor OS' try to deliver some services for You on a standard way. If You do not like this way, then write an own file system - 'independently from the OS' - with Your language, and You get as level abstraction as You can imagine.
threading : Well, I think, the threads are our best friends!
I can imagine a TASK easily, where EVERY THREADS has own outputs/console. Additionally IMHO, the 'multi-core issue' is 'semi-independent' of programming languages.'procedural execution' : Well, - hardest part -. We create the threads, 'poor compiler' just compiles 'our thoughts' for our machines. As far as I know at this moment we have procedural devices. So our software (does not mater it is an OS or application) MUST be procedural BUT(!) it could/should be runs in concurrent/parallel environment. So, until we have not got non procedural devices we have to use what we have. So, - I am sorry - I have to keep the memory-management, threading, scheduler, ... models for a 'present' OS. But(!) we can use any part of it for another non OS or semi OS implementation.
Regards, Gabor. - p.s. : I am really interesting: do You thinking about 'quantum computers?!'
Statistics: Posted by mrgs — Wed Feb 06, 2013 10:23 am
]]>