Call for Wish Lists: CFV4e-based PC and OS

Hi David,

David, I do not want to be disrespectful. All of the advice that you have given me is good and wise and should be obvious to any professional embedded system developer. And I will not discredit you by saying that stating the obvious is of little use. But it is simply not what I asked for. I guess when some people don't like the question they are asked, they choose to answer the question that they would rather have been asked. That is probably the source of our confusion.

Regards,

Paul

Reply to
Paul K. McKneely
Loading thread data ...

Hi Didi,

Thank you for the good post.

Can you say whether it is an off-the-shelf OS, your company's internal project or your own creation? What is it that you like about it? Is the raw performance of the PPC what you are wanting? When I look in the Digikey catalog there is a remendous number of PPC variants which tells me that it has been very successful in the market place. What I always tell myself is that RISC processors are fast because they have a ton of cache and they have to have an extremely fast bus interface to RAM which means a big hurdle for anyone who wants to do his own board design. It means SPICE simulation and all of that analog testing to get the timing exactly right for using the very fastest processor and RAM on the market. You are forced into this because of the low code densities on RISC processors. I decided that I want to design my own board and that many users of the new OS are also going to want to build their own boards. So I had to lower the bar for techies who want to design and build their own systems by lowering the minimum required clock rates. So by giving up highest speeds, I make the software more efficient and it will still run well. The newest CF's are still pretty fast and they need no CPU fan.

For a long time I had given up on 68K when they went to CF because they stripped the MMU away and it pretty much dashed my hopes. Believe me, I looked long and hard at the PPC and decided that I didn't want to deal with that monster. I also looked at ARM. Strange beast. It uses up almost half of its code space with branch options that don't happen very often. Its code density is not very good either. That is why they developed THUMB. But the mode switching required for its use seems to be a bad choice for improving code density. Low code density really kills performance when you run in virtual memory because your processor devours memory faster to get the same thing done. So you must page swap more often. RISC proponents say "Well just put a ton of memory in there". Then I think about how much more my more efficient system could with that much memory. The RISC argument is just a losing escalator that forces you to design to more stringent hardware requirements and buy more memory just to get the same thing done. Just remember that RISC is not new. The very first processors were RISC.

Since my target market is hobbyists and techies, I am assuming they are going to want to do a lot of assembly language. I have had plenty of people with good advice tell me that you never want to spend you time doing assembly on a PPC. They are right because it is a nightmare. Don't get me wrong. I do a lot more C than I do assembly but with the PPC you should want to do NO assembly at all. I am affraid that would put me into a straight jacket. But when I saw the MMU on the CF V4e that just came out a year ago or so, I realized that the old 68K architecture was coming back with a vengence. True, it is not pure 68K but the 4X+ performance gain over the fastest 68060 that was ever made should easily make up for that. An efficient OS will still run very well on it. Just think about how much faster virtual memory-based programs will run when the amount of page-swapping that is done will be cut in half because of the better code density.

My plan was to rewrite most of it in C so that it could be ported to the PPC later on. I don't look forward to that day if it ever comes to pass. What can I say. I just don't like the PPC.

Great post! Thank you very much.

PabloMac

Reply to
Paul K. McKneely

It is true that I answered a different question (although it is also true that I would look for open source as a positive feature when choosing an OS). But it's not so much an answer the question I would rather you had asked, but some answers to questions that I think it would help you to think about. If my posts helped, or at least made you (or anyone else) think, then that's great.

mvh.,

David

Reply to
David Brown

It is both my companys internal and my own creation. The first time I demonstrated a product with it was in 1996, the first time I shipped one was in 1998. I started writing it in the winter of 1994...

Well, you may want to look at it once more. It is _by far_ the most advanced architecture I have seen - and I think I have seen all viable choices on the market. It only looks like a monster, in fact it is very straight forward and well thought.

This is largely a myth created by the SI consultant industry, who have paid tens of thousands for some simulation package. One does need to know what one is doing, and there probably are applications where that simulation software is necessary, but routing a DDRAM is not one of them.

And that would be exactly the advice I would have given you, too. This is why I wrote VPA (Virtual Processor Assembler), it includes practically the complete CPU32 68K source syntax (user level) and generates PPC object code. The PPC instruction set is great; the assembly syntax on its own is practically unusable. Assembling code written or the CPU32 (without taking advantage of what VPA offers above that) results in 3.5 times larger code size, that is, ppc_code_length/cpu32_code_length= apr. 3.5. There are some examples - assembler lists with native codes included - at

formatting link
.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Paul K. McKneely wrote:

Reply to
Didi

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.