Hi All, This was an interesting discussion. Perhaps a bit academic at times, but if that helps to give students concurrency (and formal approaches) exposure from the beginning (and not in the last year when the brainwashing has already happened), the better. Van Roy took this approach, although he is lonely in the desert, but the result is Oz. A pitty it is rather heavy, but conceptually a master piece. On our side, we have been working on something along the lines of what Andrew describes below. You can see it as successor to the Virtuso RTOS, but it takes the same pragmatic approach to CSP. In the real world, and this is mostly embedded, code size and real-time still matters. And whether we like it or not, C is the only language really used. It is almost a must, even if for the wrong reasons. In the automotive sector it comes with the MISRA rules. Basically 140 rules telling you what you should not do when programming in C. Apparently there are another 50 rules that never made it to the standard. Bottom line is however that it works even if the MISRA rules are a good argument for dropping C altogether. If there would be an alternative readily availabe, portable, having good IDE's, code-size, low level control, etc. ... Airbus is using it for all their safety critcal software. But I must admit, nobody writes the C code anymore. It is generated from a higher level modeling environment like SCADE. Also in other domains code generation is starting to replace code writing (e.g. using matlab/simulink and other tools). C is becoming the new assembler. Hence, I decided to give it a try and let this community have a look at OpenComRTOS. This "RTOS" is actually more designed like a scalable communication layer (for "Tasks") that becomes an RTOS by adding a preemptive scheduler. It is all based on Packet Switching. It is also designed to be distrubuted by design. It is static however. Most (deeply) embedded devices can't have the overhead of dynamic support. It was also formally modeled using TLA. We had hoped that the formal model would help us to proof its correctness, but while the models do not show errors, we learned that it's main use is to help to define a better (cleaner and meaner) architecture. It helps you to reason about the architecture because of the rigor, but also because of the abstraction. Until today, we have more or less finished the L0 layer. The mapping to "CSP" is as follows: Processes -> called Tasks Channels -> called Ports In? data -> SendPacket(NW)(W)(T)(Async) Out! Data -> ReceivePacket(NW)(W)(T)(Async) PAR -> tasks are statically created at compile time. There are Start, Stop, Suspend, Resume services. Essentially, what the RTOS does is shuffeling around packets. The Packet has a(hidden) header and payload 5size defined at compile time). The major difference is that the services can be used asynchronously and that we use fixed size packets in L0. The L0 level services are sufficient to be used in real applications. Also, everything is priority ordened, also the communication, to preserve hard real-time behaviour. Our MLX targets have 32KB program memory and 2K RAM. However we spend a lot of time trying to get the smallest set of services (like primitives). It was a bit amazing to find a lot of similarities with the internals of the Transputer (where a lot of the HW support is achieved by manipulating linked lists in the hardware). We are currently defining a first L1 layer, build on L0 services. We look first at Virtuoso (counting semaphors, FIFOs, mailboxes, resource locks, memory pools, ...) but the idea is that L1 can also emulate other RTOS. (if the semantics allow it). L1 can handle any size data communication. A nice "Object" aspect of the L1 objects is that they are conceptually like Ports in a lego-like fashion. E.g. a FIFO can be seen as a Port with 2 waiting lists and 2 counters. A semaphore has one counter and one waiting list. A L0 Port just 2 waiting lists, no counters. The sorting of the waiting lists can be different. E.g. in a FIFO one sorts according to FIFO order, not in order of priority. The L2 layer is more intended for WAN or LAN type communication and soft real-time and uses L1 and L0 packets as headers. Code size: see attached file. Design: see attached file (L0, not fully complete). Formal model: see attached file. Targets: running on the MLX16 internal 16bit micro of Melexis and on top of Windows using sockets to emulate the parallel processing. (each node is a Windows process). A system generation utility generates the include files and datastructures from an xml description. The Windows version can be ported to Linux and serves simultanously as a logical simulator (task source code compiles on any target) and a 'host server'. E.g. a system can be built that has embedded targets and host PCs as nodes in the network. This is also a way to get access to host services from an embedded target. Our goal is to give OpenComRTOS a widespread distrubution. For the industrial worls we target OEM type 'Open Licenses'. An Open License provides not just binary, but also source code, formal models, design docs, test suites, etc. We envision binary licenses as well, and are willing to provide it free of charge for academic use. If anyone is interested, to use it or to engage in further cooperation, please let me know. Best regards, Eric Verhulst ---------------------- FROM : -------------------------- Eric.Verhulst@xxxxxxxxxxxxxxxxxxxxxx Skype me at: ericverhulstskype Mob. +32 477 608339 Systematic Systems Development Methodologies Trustworthy Embedded Components http://www.OpenLicenseSociety.org ----------------------------------------------------------- " "Concept" is a vague concept", L. Wittgenstein -----Original Message----- From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On Behalf Of Koehne Kai Sent: Tuesday, June 13, 2006 9:42 AM To: Andrew Delin Cc: occam-com@xxxxxxxxxx; java-threads@xxxxxxxxxx Subject: Re: The world needs process-orientation Hi Andrew, A mature occam compiler for an infrastructure like Java and .NET would definitely help to "spread the word". In fact I took part in a lecture series at my university that had exactly the same goals, the grid-occam project (http://www.dcl.hpi.uni-potsdam.de/teaching/occam/Rotor2-GridOccam-short.pdf ). If I will find the time, I will prepare a short paper for the upcoming WoTUG conference that describes the latest achievement of this project, an occam2Java compiler that supports a subset of occam 2.1. However, there are a few obstacles that you have too keep in mind. First, the language constructs of occam are difficult to map efficiently to constructs of the Java or .NET intermediate language. Second the creation of concurrency (threads) is in both platforms pretty expensive (at least in comparison to KRoC). Finally, if you really want to use occam as a kind of coordination language, you have to find a convenient method to deal with things like object creation within occam. The bottom line is maybe that an optimal POP language for these platforms would take the process model from occam, and integrate it somehow with the world of object orientation ... oh, and to be acceptable for the masses, the syntax should resemble C ;-) Maybe something like Honeysuckle? I myself have just finished my master thesis, and will deal with something completely different in my PhD project. However, I would really love to see a mature POP language for Java or .NET, and would happily volunteer to spend some spare time for this :-) Regards, Kai Koehne PS: I currently plan to publish the sources of my Occam2Java compiler at sourceforge, and would be very pleased to see if anybody would take advantage of it ;-) Have to ask the university first, though. ________________________________ Von: owner-occam-com@xxxxxxxxxx im Auftrag von Andrew Delin Gesendet: Di 13.06.2006 04:01 An: Allan McInnes; tjoccam@xxxxxxxxxxx Cc: occam-com@xxxxxxxxxx; java-threads@xxxxxxxxxx Betreff: RE: The world needs process-orientation This has been a fantastic discussion - I'm very glad there's such interest and belief in POP. I agree with the view that we need more languages that express process-oriented ideas naturally; I've found libraries that extend C++ and Java to be rather clumsy. I would be interested to collaborate in creating a small, experimental, Occam for .Net -- if anyone would like to collaborate, please get in touch. This would be a small subset of Occam/KROC constructs, for demonstration purposes of the power of POP. If we could compile Occam DLLs to include in mixed language .Net projects, this could be a powerful demonstration. The idea is that we can achieve a separation of concerns and Occam-style code can deal with the parallel aspects. We might achieve some mindshare if the language interoperates with convention blobs of code. Any takers? Andrew -----Original Message----- From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On Behalf Of Allan McInnes Sent: Tuesday, 13 June 2006 2:20 AM To: tjoccam@xxxxxxxxxxx Cc: occam-com@xxxxxxxxxx; java-threads@xxxxxxxxxx Subject: RE: The world needs process-orientation Quoting tjoccam@xxxxxxxxxxx: > > > So apart from making good business using COP > > Is there a good reason for using this acronym? Everyone else seems to > have settled on "process-oriented programming". Unanimity, if > possible, helps in being heard. The term "concurrency-oriented programming" (or COP) has been widely used in the Erlang community for a number of years. The term has since gained currency outside of the Erlang community, and I have seen it used in several different forums to refer to lightweight process-based approaches in general. Allan -- Allan McInnes <amcinnes@xxxxxxxxxx> PhD Candidate Dept. of Electrical and Computer Engineering Utah State University
Attachment:
OpenComRTOS_CodeMeasurements_27012006.pdf
Description: Adobe PDF document
Attachment:
OpenComRTOS_AR_v1.0.14.pdf
Description: Adobe PDF document
Attachment:
Formal Model OpenComRTOS.pdf
Description: Adobe PDF document