Proposal for an Operating System Interest Group for XMOS devices (XOSIG)
[Waits for objectionable noise to subside some...]
The fun or challenge of writing an OS aside, the first hurdle to clear is whether an operating system is wanted. XS-1 processors provide capabilities in hardware for threading, scheduling, locking, timing, communicating and i/o; and XC acts as the operating system language. But, those finite resources provided could be built upon (think virtualisation), and there are services provided by general purpose operating systems for which built-in capabilities are not provided in XMOS devices (think external memory and caching), and there are commercial interests in providing standard interfaces (think POSIX.4 and pthreads) or integrating with popular OS (think tapping into WindRiver's marketplace), and how about dipping further into Linux's development community.
There are several paths that XOSIG can tread on in parallel. For example:
1. virtualisation through porting micro-kernels, e.g. proprietary ENEA-OSE, Free dsp_K POSIX;
2. integration with popular O/S and Hypervisors, e.g. proprietary vxWorks, Free Linux;
3. novel research in operating system architectures e.g. MIMD or SIMD, virtual channels;
4. novel research in parallel algorithms, e.g. virtualisation, distributed micro-kernels;
and the list could go on some.
So firstly we should thrash XOSIG out, and either trash the idea as unwanted or come up with a kind of charter or set of aims.
And then we can provide some project ideas; I've started treading on path 2, and attach a draft proposal for XOSS (XS-1 operating system services) to get the ball rolling [covers hardware caching, virtual channels, vxWorks and GNU/Linux hypervisors]; feedback is of course welcome.
jhrose
Operating System Interest Group for XMOS devices (XOSIG)
-
- Active Member
- Posts: 40
- Joined: Mon Dec 14, 2009 11:18 am
Operating System Interest Group for XMOS devices (XOSIG)
You do not have the required permissions to view the files attached to this post.
-
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
Thats cool jhrose I am going to look at the pdf you have provided before I comment further.
Also you might want to see another thread started earlier today in the XEOS group :
http://www.xcore.com/groups/posts/opens ... ing-system
Definitely some common goals there no?
regards
Al
Also you might want to see another thread started earlier today in the XEOS group :
http://www.xcore.com/groups/posts/opens ... ing-system
Definitely some common goals there no?
regards
Al
-
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
On my first perusal (I've just skimmed it) great work by the way, nicely written up also.
My first question would be going the L1-L2 + memory controller route. Isn't going in that direction tying the system down to the old school of OS design?
In particular take the thread talking about how to use XMP-64 :
http://www.xcore.com/forum/viewtopic.php?f=14&t=41
Clearly there are issues when moving up the concurrency scale if we stick to the old school design. I would prefer to see the memory inside the cores to increase and to use a more distributed view of memory and processing. Otherwise we hit the same road blocks existing OS's have.
I think we need to be more radical in order to leverage the true benefit of what's on offer using the XMOS technology not just now but also what happens when we have 8,16,32 64 cores...
Thoughts?
My first question would be going the L1-L2 + memory controller route. Isn't going in that direction tying the system down to the old school of OS design?
In particular take the thread talking about how to use XMP-64 :
http://www.xcore.com/forum/viewtopic.php?f=14&t=41
Clearly there are issues when moving up the concurrency scale if we stick to the old school design. I would prefer to see the memory inside the cores to increase and to use a more distributed view of memory and processing. Otherwise we hit the same road blocks existing OS's have.
I think we need to be more radical in order to leverage the true benefit of what's on offer using the XMOS technology not just now but also what happens when we have 8,16,32 64 cores...
Thoughts?
-
- Respected Member
- Posts: 377
- Joined: Thu Dec 10, 2009 6:07 pm
There are two separate interests:
1. A new distributed OS written with concurrency in mind
2. A port of an existing OS to leverage existing bodies of knowledge, software, communities and markets
The architecture is potentially a good candidate for both. Delivering 1) doesn't necessarily need a radical rethink of the architecture or memory structures etc - just work out how to use a large number of cores efficiently. You obviously need to think about the overall system architecture as much as anything else: where is "storage" for example? The idea of using a "hard drive" might be totally obsolete for some applications. Arrays of distributed nodes including some kind of memory+processor combination, sensible ways of distributing I/O capabilities (splitting serial streams where appropriate, or redesigning the protocol etc) might be good enough.
Delivering 2) on the other hand will mean making the architecture a good target for existing OSes. That's going to take finding ways to make the system architecture more "current-OS-friendly" - which ultimately might require new silicon to do efficiently. That said, a very very earlier Unix version would probably run in the existing architecture. It all depends what you want.
1) delivers a potentially better long-term value proposition and is more speculative
2) delivers more to those with immediate applications in mind: particular markets or areas of interest.
Not sure you can shoehorn the two together into a single project... but both are definitely interesting.
1. A new distributed OS written with concurrency in mind
2. A port of an existing OS to leverage existing bodies of knowledge, software, communities and markets
The architecture is potentially a good candidate for both. Delivering 1) doesn't necessarily need a radical rethink of the architecture or memory structures etc - just work out how to use a large number of cores efficiently. You obviously need to think about the overall system architecture as much as anything else: where is "storage" for example? The idea of using a "hard drive" might be totally obsolete for some applications. Arrays of distributed nodes including some kind of memory+processor combination, sensible ways of distributing I/O capabilities (splitting serial streams where appropriate, or redesigning the protocol etc) might be good enough.
Delivering 2) on the other hand will mean making the architecture a good target for existing OSes. That's going to take finding ways to make the system architecture more "current-OS-friendly" - which ultimately might require new silicon to do efficiently. That said, a very very earlier Unix version would probably run in the existing architecture. It all depends what you want.
1) delivers a potentially better long-term value proposition and is more speculative
2) delivers more to those with immediate applications in mind: particular markets or areas of interest.
Not sure you can shoehorn the two together into a single project... but both are definitely interesting.
-
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
IMHO two different projects as you suggest Jonathan
I see older operating systems as being fundamentally designed to help control of and limit access to finite resources
Whereas what we need to exploit with the new architectures from XMOS and any event based silicon is a system which helps use near infinite resources (cores and distributed memory). In other words the two paradigms differ in purpose, not surprisingly since much has changed since the original unix design and emergence!
Don't get me wrong I love unix and linux its been my life for a couple of decades..
regards
Al
I see older operating systems as being fundamentally designed to help control of and limit access to finite resources
Whereas what we need to exploit with the new architectures from XMOS and any event based silicon is a system which helps use near infinite resources (cores and distributed memory). In other words the two paradigms differ in purpose, not surprisingly since much has changed since the original unix design and emergence!
Don't get me wrong I love unix and linux its been my life for a couple of decades..
regards
Al
-
- Active Member
- Posts: 40
- Joined: Mon Dec 14, 2009 11:18 am
Hei,
Thanks for the replies.
XOSIG:
XOSS:
Firstly, XOSS is not an operating system; it is really just an interface. In software, it simply extends functions already present in the XS-1 and XC. And in hardware it provides one way to shoehorn more memory in and get at it in several useful ways from both sides of the interface.
Linux/UNIX and XOSS:
Definitely not on the XS-1. Monolithic (legacy) operating systems belong on host processor nodes only. XOSS (or XNET) is a way to interface them to XS-1 networks, a bridge if you like, and the XS-1 Compute Module (XCOM) makes no requirement on the XS-1 array or network lurking behind it. You are free to build an XS-1 array backend with pure XS-1s or a mix of XCOMs; you are also free to develop a new distributed OS that is highly concurrent, to run on the backend; XOSS has nothing to say on these matters. I guess that makes it Jonathon's project number 2.
My concern in XOSS is very practical and not at all theoretical, and the L2 memory brings several advantages, for example:
1. pushing L2 out to FPGA provides the FPGA owner with flexibility to spend whatever they like in BRAM;
2. low performance overhead in placing code or data into external memory from a host processor by using the FPGA hardware to swap it in.
The XOSS FPGA could almost be replaced with an array of XS-1's; you would need 8 of them with 64K just to replace the 512KB of BRAM, and then some more XS-1s to provide the interfaces and as I believe 400MHz is not doable you would still need the FPGA or something else to drive a DDR device. And it is quite possible to do away with the FPGA and DDR, and reduce XNET downto the GPIO-based connection; but without DDR and paging you loose a lot of capability in the interface.
Thanks for the replies.
XOSIG:
Sorry I didn't see your XEOS group post, and am unable to read it now without apparently becomming a group member. But wearing my philosophical hat, I draw a clear distinction between Open Source and Free (capital F) software, and have no strong interest in the former. I suggest if people come up with a set of aims for XOSIG and if these overlap XEOS heavily, then to merge the groups. Though I think XOSIG has proprietary interests that even Open Source would have problems with (embracing vxWorks or OSE for example).you might want to see another thread started earlier today in the XEOS group
XOSS:
Firstly, XOSS is not an operating system; it is really just an interface. In software, it simply extends functions already present in the XS-1 and XC. And in hardware it provides one way to shoehorn more memory in and get at it in several useful ways from both sides of the interface.
Linux/UNIX and XOSS:
Definitely not on the XS-1. Monolithic (legacy) operating systems belong on host processor nodes only. XOSS (or XNET) is a way to interface them to XS-1 networks, a bridge if you like, and the XS-1 Compute Module (XCOM) makes no requirement on the XS-1 array or network lurking behind it. You are free to build an XS-1 array backend with pure XS-1s or a mix of XCOMs; you are also free to develop a new distributed OS that is highly concurrent, to run on the backend; XOSS has nothing to say on these matters. I guess that makes it Jonathon's project number 2.
Well absolutely. Ideally, we would just throw additional processors into our system designs and spread our software around them in a nice way. On one hand, maybe that's what XMOS would encourage us to do. But on the other, the reality of manufacturing cost, power consumption, and such, result in a practical need to compromise. For example, increasing on-chip SRAM in XS-1 cores would be costly, where the chips are manufactured downto a price (to compete pound-for-pound with FPGA and such).Clearly there are issues when moving up the concurrency scale...
My concern in XOSS is very practical and not at all theoretical, and the L2 memory brings several advantages, for example:
1. pushing L2 out to FPGA provides the FPGA owner with flexibility to spend whatever they like in BRAM;
2. low performance overhead in placing code or data into external memory from a host processor by using the FPGA hardware to swap it in.
The XOSS FPGA could almost be replaced with an array of XS-1's; you would need 8 of them with 64K just to replace the 512KB of BRAM, and then some more XS-1s to provide the interfaces and as I believe 400MHz is not doable you would still need the FPGA or something else to drive a DDR device. And it is quite possible to do away with the FPGA and DDR, and reduce XNET downto the GPIO-based connection; but without DDR and paging you loose a lot of capability in the interface.
-
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
Apologies for the group restrictions it the way they are setup. It was a toss up on a new topic thread or not, I had a similar conversation with Jason about when to use forum threads and group posts, he also thought in this case the group was more appropriate. The thread itself was started however as the result of a previous thread in the forum here around porting linux as a possible OS idea for XMOS http://www.xcore.com/forum/viewtopic.php?f=17&t=29. Likewise I also perceive distinctions between Free as in free beer and Free as in Libre when it comes to software but try to be pragmatic and accommodating if the community benefits in the long run rather than religious.XOSIG:Sorry I didn't see your XEOS group post, and am unable to read it now without apparently becomming a group member. But wearing my philosophical hat, I draw a clear distinction between Open Source and Free (capital F) software, and have no strong interest in the former. I suggest if people come up with a set of aims for XOSIG and if these overlap XEOS heavily, then to merge the groups. Though I think XOSIG has proprietary interests that even Open Source would have problems with (embracing vxWorks or OSE for example).you might want to see another thread started earlier today in the XEOS group
Apologies if I didn't understand your proposal on first read, I have now read through it several times, it an excellent piece of work and clearly very well thought out. fundamentally however we are talking at cross purposes as this is different at many levels to the conversation in the other thread. I will watch XOSIG with a great deal of interest as it develops, and look forward to perhaps using it as it matures.XOSS & XOSIG
regards
Al
-
- Experienced Member
- Posts: 65
- Joined: Fri Dec 18, 2009 1:27 pm
- Location: The Interzone
I like the idea of there being more than one project here.
From my own perspective there are in fact 3.
Project 1
jhrose:-
I have read your proposal (interesting and well written, I agree) and chewed over it a while. This I think is perhaps one project in and of itself and feels to target itself towards the server/desktop/PC classes of applications that are already fulfilled by other architectures. (PowerPC, Xeon, Intel X86 and AMD Clones). Virtualisation, Hypervisors and MMU's and the Memory cacheing needed to support this are definitely that category of application. IMHO I am not convinced that the Xcores are those sorts of processor or are targeted at those sorts of applications sets. To make them so (and there is perhaps mileage in this) requires a nontrivial redesign of the silicon. Perhaps also a shift in their paradigm.
The point re older operating systems (I am thinking full OS's here) is well taken and fits into the above category.
Project 2
Is arguably less of a paradigm shift, it just needs some more resource (Memory) or even an external memory interface on at least one exisiting model. Say the L1.
This is the cut down legacy OS route ie uClinux. Which gives us a quick and not insubstantial shot of existing code base that can be adapted to better suit the XMOS architecture on a needs basis.
Project 3
A completely new OS. That either is sufficiently similar in idea to existing OS methods to make entry easy to the uninitiated, or is so incredibly simple that it is easy for the newcomer. Again when considering OS's even specifically tailored and written ones they take up resources and those are scarce in the current offering.
In Summary
There is mileage in Project 1, take the Cell BE processor as a case in point. Think of it as a Project 1 new processor with full OS and existing xcores as applications processors. Doing so makes sit easier to see the potential. Very heavy additional resource requirements.
Project 2 offers a realisable short term commercial benefit to XMOS. uClinux is already embedded into commercial devices and their is a not insubstantial open source code base waiting to be tapped. Like Project 1 not viable without more resource but requires far less that Project 1.
Project 3 is doable and would benefit greatly from a shot of additional resources and will take a bit of lateral thought together with clever coding and not insignificant development time. The code base and applications is all write from scratch on a needs basis. Development on this could start right away. Perhaps by creating upgradeable code libraries for the XMOS IDE. Great as application building blocks (Think Arduino) and developing over time into an OS. Resource limitations will become rapidly apparent and OS overhead may be unpopular in an embedded application where resources are found to be insufficient.
Over all some promising ideas and directions. All are perhaps a little ambitious for the resources that are currently available. Or are they ?? What do you guys think ??
From my own perspective there are in fact 3.
Project 1
jhrose:-
I have read your proposal (interesting and well written, I agree) and chewed over it a while. This I think is perhaps one project in and of itself and feels to target itself towards the server/desktop/PC classes of applications that are already fulfilled by other architectures. (PowerPC, Xeon, Intel X86 and AMD Clones). Virtualisation, Hypervisors and MMU's and the Memory cacheing needed to support this are definitely that category of application. IMHO I am not convinced that the Xcores are those sorts of processor or are targeted at those sorts of applications sets. To make them so (and there is perhaps mileage in this) requires a nontrivial redesign of the silicon. Perhaps also a shift in their paradigm.
The point re older operating systems (I am thinking full OS's here) is well taken and fits into the above category.
Project 2
Is arguably less of a paradigm shift, it just needs some more resource (Memory) or even an external memory interface on at least one exisiting model. Say the L1.
This is the cut down legacy OS route ie uClinux. Which gives us a quick and not insubstantial shot of existing code base that can be adapted to better suit the XMOS architecture on a needs basis.
Project 3
A completely new OS. That either is sufficiently similar in idea to existing OS methods to make entry easy to the uninitiated, or is so incredibly simple that it is easy for the newcomer. Again when considering OS's even specifically tailored and written ones they take up resources and those are scarce in the current offering.
In Summary
There is mileage in Project 1, take the Cell BE processor as a case in point. Think of it as a Project 1 new processor with full OS and existing xcores as applications processors. Doing so makes sit easier to see the potential. Very heavy additional resource requirements.
Project 2 offers a realisable short term commercial benefit to XMOS. uClinux is already embedded into commercial devices and their is a not insubstantial open source code base waiting to be tapped. Like Project 1 not viable without more resource but requires far less that Project 1.
Project 3 is doable and would benefit greatly from a shot of additional resources and will take a bit of lateral thought together with clever coding and not insignificant development time. The code base and applications is all write from scratch on a needs basis. Development on this could start right away. Perhaps by creating upgradeable code libraries for the XMOS IDE. Great as application building blocks (Think Arduino) and developing over time into an OS. Resource limitations will become rapidly apparent and OS overhead may be unpopular in an embedded application where resources are found to be insufficient.
Over all some promising ideas and directions. All are perhaps a little ambitious for the resources that are currently available. Or are they ?? What do you guys think ??
"Dr Fingers Schaefer, The Lobotomy Kid"
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
-
- Active Member
- Posts: 40
- Joined: Mon Dec 14, 2009 11:18 am
Hei,
I hadn't viewed the XOSS/XS-1 fulfilling some desktop role. Rather, my view of XOSS/XS-1 is of a (slave) embedded co-processor (array), that is hosted by a master (like PowerPC or IntelX86) which may in turn be running vxWorks or Linux. This (master) processor could itself be embedded in some system, like a telephone exchange, or it could be on the desktop running a GUI for example.
The point about hypervisors in vxWorks or Linux is to extend those operating systems on existing processors (like PowerPC or IntelX86) with an interface to the XS-1 slave (array). And virtual channels would allow vxWorks or Linux processes to communicate with XS-1 threads through an interface, like a pipe.
In particular XOSS/XS-1 requires no silicon change. But it does require either an extension to XC (or the compiler/linker anyway) and/or provision of a library;and it requires a board to be made up, on which an XS-1 and an FPGA are mounted and interfaced, together with an external interface to the host (master) processor.
The XS-1 has no external memory interface. I think it would be a costly addition, but when that arrives uCLinux would start to make more sense. To get an idea of resource needs, perhaps take a look at the blackfin DSP to which uCLinux is ported: http://blackfin.uclinux.org/gf/. But until an EMIF is provided, we have the existing XS-1 (L/G families) to work with.
XOSIG should encourage many ideas, as you suggest. I'm currently drafting some notes on this and hope to post them in the group at http://www.xcore.com/groups/xmos-operat ... roup-xosig.I like the idea of there being more than one project here.
With regard to XOSS, it is not an operating system but is a set of services, really just an interface. In software, it simply extends functions already present in the XS-1 and XC. And in hardware it provides one way to shoehorn more memory in and get at it in several useful ways from both sides of the interface.Project 1
I hadn't viewed the XOSS/XS-1 fulfilling some desktop role. Rather, my view of XOSS/XS-1 is of a (slave) embedded co-processor (array), that is hosted by a master (like PowerPC or IntelX86) which may in turn be running vxWorks or Linux. This (master) processor could itself be embedded in some system, like a telephone exchange, or it could be on the desktop running a GUI for example.
The point about hypervisors in vxWorks or Linux is to extend those operating systems on existing processors (like PowerPC or IntelX86) with an interface to the XS-1 slave (array). And virtual channels would allow vxWorks or Linux processes to communicate with XS-1 threads through an interface, like a pipe.
In particular XOSS/XS-1 requires no silicon change. But it does require either an extension to XC (or the compiler/linker anyway) and/or provision of a library;and it requires a board to be made up, on which an XS-1 and an FPGA are mounted and interfaced, together with an external interface to the host (master) processor.
I guess from other forum postings that uCLinux is a passion that you would like to have on XS-1s in some form. And of course the appeal is clear, however, I think the resource needs would limit any useful outcome presently. And, particularly with the 64KB RAM in mind, do you mean to stop at Linux (i.e. the kernel), or do you mean to provide various libraries and drivers to make it a useful operating system for programmers, or even to provide a shell for interactive use?Project 2
The XS-1 has no external memory interface. I think it would be a costly addition, but when that arrives uCLinux would start to make more sense. To get an idea of resource needs, perhaps take a look at the blackfin DSP to which uCLinux is ported: http://blackfin.uclinux.org/gf/. But until an EMIF is provided, we have the existing XS-1 (L/G families) to work with.
With regard to a brand new operating system, perhaps you can detail your ideas to make them clearer. In the meantime, as Folknology suggested, you could take a look at Occam-pi and KRoC http://www.cs.kent.ac.uk/research/groups/sys/kroc.html as a "new" working model. I am currently drafting some notes on this and hope to post them in the XOSIG group.Project 3
-
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
I did think about porting Fred Barnes RMoX http://www.cs.kent.ac.uk/research/groups/sys/rmox.html using XC/C on XMOS but even this seems a little old school in its approach and goals. It does however have a lot of interesting ideas/code and is well worth checking out. I still haven't completely killed the idea of a port..