I have been developing an OS for about 18 years. With the CFV4e out now having an excellent MMU, it looks like it is time to get serious (again). I would love to have feedback from those of you who would like to give me their opinions on what the ideal desktop PC and OS would be like. Please post your opinions to for all to see and respond to. Squeaky wheels will probably get most of the grease. I will not bias you on any specifics but I will say that this OS is targeted at high efficiency and low bloat and will have capabilities beyond today's system software. Target market is serious hobbyists and techies that like software that is powerful and easy to use and want excellent documentation and like to do their development without wearing a straight jacket. Let me also say that the software will not be open source. As opposed to many others in the open source community, I believe that gifted developers should be paid for their hard work instead of having to give their talents away in an effort to twart the evil empires of the computer world. All sincere opinions are welcome.
comp.sys.m68k is pretty much a dead newsgroup - almost no one posts there. ColdFire users are much more likely to be found here in comp.arch.embedded than comp.sys.m68k, so you are best here (or cross-posting).
Another good contact point would be the wildrice ColdFire mailing list.
Many people and companies manage to combine providing open source software with making money. It's not necessarily an easy business model, but neither is selling a closed source embedded OS an easy business model. If you are seriously hoping to make money from your OS, your first priorities have to be making it popular, and gathering feedback and improvements. Unless you can tie your distribution with something else (a compiler, a demo board, or something else that sells by itself), open source is pretty much the only way you could get a significant user base. For example, if you have a web site where I can download the code under a reasonable (from *my* viewpoint) license, I might well do it of curiosity - and perhaps I'll like it and take further steps. If I have to fill out forms, or there are limits to the code in terms of time, or object-only code - there's no way I'd bother. Once you are a big name, it's possible to do things like that - companies like Wind River can sell closed source vxWorks, because they already have a solid reputation and user base (note that Wind River also make money selling an open source embedded Linux distribution).
Have a look at
formatting link
for a good example of an open source rtos with a solid business model.
As for your OS itself, I can't give you many comments since you haven't given much technical information! However, you seem to want to make a small, compact and efficient OS taking advantage of the MMU on high-end ColdFires. That sounds to me like an oxymoron - MMU's exist precisely to make it possible to write big, powerful and flexible OS's while keeping the system manageable and reliable (by separating the processes' memory). Small, compact and efficient systems do not, as a rule, use an MMU. At most, they use it in a simplistic way (for example, set up a block of kernel-accessible memory, and application-accessible memory, and leave it that way throughout the runtime of the system). To quote from the MCF547x literature:
Features of the V4e core include the following:
Memory management unit (MMU) that enables process isolation for a high level of reliability and security; expanded use of protected-mode OS, such as Linux® OS
That is the reason why is the best place to post. This news group is so busy that this thread will soon be buried in unrelated posts. I don't like to have meetings in hallways. Do you?
Thanks. I'll check into it.
I explained that I don't want to bias people's comments. I just gave a few features just to let people know what the target market is. No more. My original call was not for examination of the OS. It was a call for wish lists. I would think that everyone has one and you shouldn't have to see a ready product in front of you to know what you would like to see in an operating system... unless, of course, you have no imagination or you don't have any frustrations with working with software you don't like. (I suspect that the two above may go hand-in-hand).
I re-read my post and I never used the word "small" anywhere in there. The word I used was "efficient". I see that I didn't even use the word "compact". In my opinion, "bloated" doesn't mean "large". A skinny and lean 1 ton Allosaurus is "large" but a fat 1 ton mouse is "bloated".
Good reasons to an MMU to the ColdFire achitecture, huh! What I was wanting from people is to find out their peaves and inner desires. No that the HW is here, it is time to get to work...
That's fine if you've arranged the meeting in advance and people know its there. If you are hoping to collect people along the way, then the hallway is a lot better than an empty room.
I think you may be expecting a bit too much. If you post a list of current or proposed features, people might give you a few more ideas or changes. But at the moment, we have little idea what you are considering - OS's vary enormously in scope. Or are you hoping that dozens of people will suddenly join you in animated conversation in an effectively dedicated newsgroup, working together to give you a design specification for an OS that you will then sell back to them?
High efficiency and low bloat do not necessarily mean small, that is true. But in the absence of any other information about features, its the obvious implication.
Basically, you want an MMU if your system can start new programs with minimal risk to existing running programs. On an embedded system you often want to have precise control over exactly which processes are running, and all of them are important to the system and are well tested. In such a system, the MMU gives you very little, and costs significantly in complications and runtime efficiency - that's why people sometimes actively choose to run non-MMU uLinux on processors that have an MMU and support full Linux.
This is only partly true. The MMU takes some RAM for the page table - and not of a negligible size for many embedded applications indeed - but that is about all one has to pay for it if done properly. I have done this in DPS and it works well. I do have the option to boot with the MMU off - just run with as much RAM there is, like in the old CPU32/68k days - but I rarely use it if at all (I remember booting like that a few times last few years in order to check if I had a page translation issue, which was never the case on all of these occasions, and switched back :-) ). I did consider the Coldfire when it appeared, but it was too late, the PPC was way ahead (still is and the gap seems to keep on widening). Porting DPS to Coldfire would be fairly easy, but I have not had a reason to do that yet (and I don't see it coming... yet :-) ).
No, that's not all you pay. The cost in ram is not normally relevant, and offset by other memory-related benefits like allowing more sophisticated heap management.
The two costs of an MMU are the extra time for task switching (you potentially have a lot more data to save and restore, not just the cpu's main registers), and the increased latency for all memory accesses as addresses pass through layers of indirection. (I'm ignoring virtual memory here - it's not often used in embedded systems, and it's clear that paging will cause large delays).
Depending on the type of MMU, trying to read data from memory may need three or more reads of information from the page table structures. Assuming this is all in dram, the worst case latency for reading data is then much larger when using the MMU (and worst-case scenarios are highly relevant in this group). Even at the best of times, when everything needed is in caches or specialised buffers, the MMU will add a number of clock cycles to every access as addresses are checked for validity and translated from virtual to absolute address.
Much of this depends on the type and sophistication of the MMU. If it is nothing much more than a few boundary checks and offsets, supporting a small fixed number of regions at a time, then all the settings will be in the core, and the extra latency will be minimal. For example, the MMU in the ColdFire v4e under discussion does not add any latency if the relevant entries are in the TLB. A more sophisticated MMU, such as used in the x86 architecture, will always add latency (it was quite significant in the 486 days - for newer cores, the memory latencies are already so high that the MMU delays are just noise). However, to quote from the MCF5475 manual:
Harvard TLB provides 97% of baseline performance on large embedded applications using equivalent V4 without MMU support as a baseline.
In other words, the real cost of the MMU is 3% performance. Is it worth the cost? Maybe, that depends on the situation. But it is certainly not irrelevant.
Not necessarily. If the systems address space is up to 4G mapped into say 64M, switching a task does not take any more saving than if you have no MMU.
This is again only partly true. Obviously page translation does take some extra overhead (typically negligible), so task switch latency may be somewhat increased. However, the latency which really matters in an embedded (any?) system is IRQ latency, and it does not have to be increased at all in a PPC processor if the MMU is properly used (as in DPS :-) ), the IRQ stack is maintained in a BAT memory region. So overall I would say that while I might agree that the penalty for using the MMU is not 0 other than the PTE table, it is practically 0, at least on the PPC parts I have programmed it for.
I don't follow you at all here - perhaps I wasn't clear in what I wrote. When switching tasks, an OS must store the current task's state and load the state of a new task. This task state will obviously include all the registers in the cpu. If you have a complex memory setup, then this too must be saved and restored so that the new tasks sees its view of virtual memory, rather than that of the old one. This is in addition to any other work the OS must do to track this change in the view of memory.
Here I am referring to the time taken between the cpu requesting data at a given virtual address, and the memory controller starting to perform the read at the appropriate physical address (writes are easily buffered, it's reads that affect visible performance). This translation requires steps involving identifying the appropriate memory area, checking its bounds and other access privileges, and adding offsets. There may be several layers involved, or other operations (such as if paged memory is in use). All this takes time. With a small, simple MMU and a relatively low (for a high-end cpu) clock speed, it can maybe be done within a clock cycle if everything is in caches and TLB's. For more complex systems, it will take multiple clock cycles, and if MMU data needs to be loaded from memory, you'll get even longer delays. This is a performance hit for every single access, not something restricted to task switches.
And while I agree that interrupt latency is often critical in embedded systems, a real-time system requires bounded worst-case runtimes on any real-time task - the MMU will normally make that runtime slightly slower, and it will also make it less predictable.
I don't know how big these time costs would be in real, practical cases
- nor do I know how it would balance against any time savings that could be achieved by taking advantage of an MMU. But there is no doubt that MMUs cost - there are good reasons why you don't get MMUs in smaller cpus, and why people choose to disable MMUs in some cases. Clearly, there are also good reasons for wanting to use an MMU, and for larger or more complex setups their benefit outweighs their costs.
No. Only the general purpose registers and a few special purpose registers, the same set must be saved with and without VM on (within a 4G address space, that is).
I understood that, but it takes no time penalty at all for block address translation, and BAT registers are an integral part of the PPC MMU. So IRQ latency does not have to cost anything additional in a VM system.
Well, that is correct, I did not take into account the cost of the MMU silicon itself indeed. Disabling the MMU makes sense only in order to save programming expertise and effort, which is also a valid point, of course.
This all sounds like a pretty simple MMU - which PPC are you using here? Not that there is anything wrong with simple - it gives you a bit of added protection and flexibility, and in this case does not cost anything in terms of access latency. The ColdFire v4e mentioned by the OP has a bit more sophisticated MMU, including tables in ram. It also seems to be without added latency when you get a TLB hit, but will cost you (obviously) on a TLB miss. Many MMUs are a lot more complex, and have several layers of indirection - very nice with a large general purpose OS, but unnecessarily slow and complex on most embedded systems, which is why people often don't use them on embedded systems even if they are available. But I appreciate your point that some MMUs at least are practically cost-free.
Well they do not get much more complex than that. The PPC MMU is described in detail in the "PPC programing environments manual" or sort of title, easy to locate. My experience is with the 603e (or G2) core, which implements the complete MMU (and is practically the same on all subsequent 32-bit PPC parts). You seem to miss the fact that one gets _both_ page and block address translation for the same logical address space.
Actually it gives you all you can expect from an MMU. How simple or complex this may be is a relative judgement which can be done only by knowing both entities under comparison.
Tables in RAM - typically called page translation tables - are also used by the PPC and DPS employs them (like other OS-es do) to implement VM. However, ther also is BAT, which allows IRQ latency to be kept as low as on non-VM systems.
Not really. The design specifications are already pretty well nailed down. What I was wanting from people was their off-the-cuff remarks on what they would like to see in a general-purpose operating that they might view as a good replacement for Windows or the Mac. The reason I went to developers is because I know they will not give the sort of useless input that Joe Blow walking the streets would give such as "I want it to work like the Mac" or "I want it to be totally transparent so I don't have to think about what I am doing". All I wanted was to poll the developer community and guage what I have been developing over the years to see how well it lines up with what other developers want to see. But it seems like developers are so paranoid about someone stealing their ideas that they just want to look at what you have done so they can steal your ideas instead and run with it. People like Homer who are hypocrits wave the open source flag to try to get your ideas for free but they are unwilling to give anything in return. That's not how open source is supposed to work but when they give a lot of their work away and don't get paid for it, many of them just get bitter like Homer. That is why I think that the current open source phenomenon is somewhat of a fad and when the population get tired of other people making lots of money off their work and they get nothing, they will change their tune. But it may be the next generation that decides "I don't want to get screwed like my father did with open source". If developers are so tight-lipped about what they would like to see in a new operating system because someone might steal their ideas, then it looks like I may have to look elsewhere for the population poll that I am looking for. If I can't get any useful feedback then I will probably just go on developing as a hobby because I like it so much. I will figure out another way to make a living. But if it is a success, then my company and my partner developers (and ultimately the end users) should be the winners in the long run.
Windows and MacOS are not replaceable with a one-man project, and you are not going to get anyone to take you seriously if you are making wild claims of equivalence with absolutely no evidence to back them up. When you post to comp.arch.embedded about a general purpose OS, people think you are referring to a general purpose embedded OS - a realistic project for a single developer. But when you suggest it might be a replacement for Windows or the Mac, it's hard to understand what you are talking about.
No, it's not that at all. People are often willing to *share* their code or their ideas - they will give their time and effort to an open source project, knowing that it benefits others, and that they will benefit from contributions from other people. That's why commercial businesses also do open source development - for some types of software, the development community surrounding the project is worth more than the software itself, so the company makes a business from writing open source software and giving it away, while selling support or extra functionality. But what you are asking people to do is give you their time and thoughts, for nothing in return except a vague suggestion that you might sell them an OS at a later date. I've given such time and thought to other closed-source commercial developers in the past - but that's in cases where I know they are providing a service to the development community and I'm making a contribution to the community at large through that developer. It takes time for a person and a product to get a reputation that encourages that sort of participation - your 18 year old vapourware does not have that reputation.
Suppose I told you I was planning to build satellites in my garage (that's perhaps comparable in scope to a new desktop OS), and asked you for a list of things a satellite should do. How much effort would you be willing to contribute, knowing that the only beneficiary to a finished product would be me?
In any large group, there are crackpots, fanatics and hypocrites - c.o.l.a. is certainly no exception. And yes, there are plenty of open source developers out there who feel they have been taken advantage of, either by other open source developers, by closed source developers, or by users. The same applies to closed source developers, and probably pretty much *any* group of people in the world, especially those who show a little kindness or sharing spirit.
There has been open source software development since the first computers existed. It did not really have formalised licenses, nor were the terms "open source" or "free software" used, until bulletin boards and the Internet started making it easier to pass code around, and the legal battles of BSD vs. Unix got the lawyers involved. But the idea of sharing code has existed for generations, and most people are pretty confident that it will continue to exist.
Presumably, since no one has seen your OS, you have had some other means of income over the last 18 years? If you've got something that works, and is worth selling, then try *selling* it. Once you've got something out there, you can collect feedback.
Note that when I suggested you use an open source development model, it was not because I think it is somehow the "right" thing to do, or that I don't think you should make money from your work. I suggested it because, based solely on this newsgroup thread, I don't believe you will have any success if you do *not* release the code as open source. You might only get paid by 1% of your users - but 1% of 10,000 users is a lot more than 100% of 10 users.
Where do you see the Coldfire in that connection? I have an OS which is more than good enough to replace either - but the fact that it needs a PPC platform is a large enough roadblock so far, and there is some PPC based hardware out there, only nothing documented to be useful. With CF, things seem pretty hopeless to me... BTW, if your source code is 68K assembly, it can be ported easily to PPC using my VPA (which runs under DPS but system dependency is minor, file i/o mostly). Some samples are at
To give feedback comparable to what I am asking for I would say:
You need a transmitter and a receiver that can send and receive over very long distances. You will probably need a parabolic dish to concentrate the signal.
You will need electronics that can tolerate extremely low temperatures.
It needs batteries because the Earth will block the sun almost half of the time.
You will need a source of energy to recharge the batteries, probably solar panels.
It will need sophisticated electronics to control the power, and route the signals and will need a good protocol to communicate with the ground stations.
You will need rad-hardened electronics because the radiation out in space is far more than it is on the surface of the Earth.
You will need a good launch vehicle to put it into orbit.
As for funding, you are on your own!
How was that? It didn't even take me a lifetime of dedicated work to make a pretty useful list. That's comparable to what I was asking for :) I'm sorry if it was too much to ask for.
You have already spent much more time telling me that I am asking for too much than it would have taken you to give me the simple "wish list" of things you would like to see in a general purpose OS that I originally asked for. Two other people used far fewer words and have given me much more useful feedback (in a single post each ) than your several posts. At least I have to give you credit for being more polite than Homer. I think you may be over-stressed from work. I tend to make mountains out of mole-hills when I am in need of a vacation myself.
But you have reminded me of things that I should be reminded of because they are important. I thank you for that. I have taken enough of your time. Thank you for the feedback.
Wonderful. A list of the perfectly obvious, as demonstrated by the state of the art as currently practiced. You've failed to contribute _anything_ novel at all.
Since you presumably know exactly what is good and bad about Win and Mac OS, you should similarly have no trouble creating a product that has all the good things, and leaves out all the bad things. Be sure and drop us a line when you're done.
As Gene wrote, a list of standard features is of little use to someone who already has the basic OS in place - you need features that would make your OS stand out.
I have spent a fair amount of time trying to give you advice and suggestions on what I think could make a project such as yours succeed. There's a lot more to making an embedded OS succeed in the market place than just the technical details of the software - that's the
*easy* part. I'm not sure I got my points through, but I tried.
The MPC603e has the BAT system as a shortcut for when you need simple, fast and predictable accesses (such as for minimum IRQ latency, or for handling critical exceptions), and a fuller MMU system with tables of memory segments and support for paging, for when you need more complex memory arrangements, and are willing to pay the price. This is the best of both worlds - you can use one mechanism, or both, or neither, according to your needs. But although I could not find any timing information in my brief read of the MPC603e manual, it's quite clear that the full MMU system adds latency - that's why the BAT system exists!
I can't be bothered to suscribe comp.sys.m68k just for answering, so here.
My wishlist is simple. I want to run to be able to run all available programs, be it originally meant for Mac, Linux, CPM, MSDOS, Windows 3.11, Windows XP, Windows NT, VAX VMS etc.
(Linux at the moment comes pretty close, so you'll have to hurry to get market share.)
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Yep. Perfectly obvious to techies. You would have lost credibility with me if you hadn't thought it is obvious. But I think something that many of you techies are failing to understand is that there is a difference between development and market research. You guys walk around with a one track mind puffing your chests out babbling "innovate... inovate" and show your machismo for how smart you guys are (and you guys ARE very smart) then you go down to the beach and a beautiful chick walks past you and she mumbles to herself "what a geek" and then she drops into a little booth to buy some expensive lipstick. You guys didn't make any money on that one (or any chick points) but the lipstick manufacturer earned some money because the gooey low-tech stuff was red. Not very innovative but it sold. In market research, you try to poll people's preferences. Those preferences may not be innovative at all but that is what people want. And preferences can often be mutually exclusive. It has everything to do with whether a person will purchase and like your product or not. You know, no color is innovative or novel because we have pretty much seen them all. But for some strange reason people say they have their favorite color. Why is that?
Gene, you and I both know that "good" and "bad" are opinions. I am simply asking for your opinion. If you are unwilling to do that then let's give someone else the chance to voice their opinion on what is good and bad about the general purpose operating systems on the market.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.