another bizarre architecture
in [Embedded]
|
From: Jerry Avins on 8 Feb 2007 11:06 Jonathan Kirwan wrote: ... > Hmm. Never mind about Lua. It's not c. Just c-like. But there do > seem to be other c interpreters out there that are c and not c-like, > given some of the google results I've just skimmed. Whatever happened to InstantC? I have a copy for DOS available to anyone who wants it. Just ask. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
From: Roberto Waltman on 8 Feb 2007 11:33 "rickman" wrote: >... >If C had an easy way to interactively test routines as they were >written, I would say C was the clear winner (no stack to fuss with). Your wish has been granted: http://www.softintegration.com/products/chstandard/ There are (were?) a few other more or less completed C interpreters. From memory, (not time to search now,) there was one included with CERN's Root project, the UPS debugger, Instant-C mentioned elsethread, etc. Roberto Waltman [ Please reply to the group, return address is invalid ]
From: John Devereux on 8 Feb 2007 11:57 "rickman" <gnuarm(a)gmail.com> writes: > On Feb 7, 11:35 pm, CBFalconer <cbfalco...(a)yahoo.com> wrote: >> rickman wrote: >> > CBFalconer <cbfalco...(a)yahoo.com> wrote: >> >> Didi wrote: >> >> ... snip ... >> >> >>> The most critical rule I believe I have defined for myself is >> >>> "never write at once more than you can hold in your head". >> >>> After debugging a piece which is < your brain capacity, move >> >>> on to the next piece :-). >> >> >> The corollary to that is "keep your functions short. One >> >> screenful is usually enough"/ >> >> > Interesting. I was taught (back in the days of a CRT being a >> > separate entity from the computer) the screenful rule of "thumb". >> > But I have been working lately with Forth and am becomming a firm >> > believer in the smaller the routine, the better. This certainly >> > works in Forth and works well. >> >> These all derive from the functioning of the brain. It has been >> experimentally determined that the human brain cannot accurately >> keep track of more than roughly six or seven entities at once. >> This is known as the 'rule of seven'. > > I recall a thread somewhere that discussed the origin of this "rule". > That conversation traced it to a paper by one of the participants in > the thread who said his original paper had to do with perception, not > thinking. He claimed that the human senses could distinguish easily > approximately seven levels of volume, tone, color and so on. That is > not to say that we can only see seven colors, but if you were to > attach them to objects or menus or similar, using much more than seven > makes them hard to distinguish. > > I'm not disagreeing that seven is a good number for things you can > hold in your head short term, I am saying that I have not seen a > source for this claim. I'm pretty sure the magic number for me is a > bit less, perhaps five. That may be why I have trouble with the stack > when I program in Forth and have to make extensive use of stack > notation. The way I heard it was that this is the number of objects that you can look at and *know* instantly how many there are, without actually counting them. I use this sometime when counting out parts that are say scattered on a table. I can "count" them 5 at a time, no matter the configuration of each group of 5. If you recall in the movie the "rain man" could do exactly this, but with hundreds of items. I can just manage 5... -- John Devereux
From: John Larkin on 8 Feb 2007 12:24 On Thu, 08 Feb 2007 09:37:52 +0100, David Brown <david(a)westcontrol.removethisbit.com> wrote: >John Larkin wrote: >> On Mon, 05 Feb 2007 09:45:44 +0100, David Brown >> <david(a)westcontrol.removethisbit.com> wrote: >> >>> John Larkin wrote: >>>> On Fri, 02 Feb 2007 15:13:53 GMT, Vladimir Vassilevsky >>>> <antispam_bogus(a)hotmail.com> wrote: >>>> >>>>> Jan Panteltje wrote: >>>>> >>>>> >>>>>>> It is better to stay on the earth rather then fall on somebody's head. >>>>>>> Masking the errors is the worst practice. >>>>>> Yes that is true. >>>>>> But you have to try one day to fly.... Errors will show you where to improve. >>>>> Deadlines. That's another reason for the software to be the far from >>>>> perfect. >>>> >>>> So, you will actually release software that you know is buggy, or that >>>> you haven't tested, because of some schedule? Please tell me who you >>>> work for, so I can be sure to never buy their stuff. >>>> >>> John, this is comp.arch.embedded - the answer is *always* "it depends". >>> For some products, it is vital to hit the schedule - even if there are >>> known bugs or problems. Perhaps you ship the hardware now, and upgrade >>> the software later - perhaps you ship the whole thing even with its >>> outstanding problems. For other products, you have to set the highest >>> possible standards, and quality cannot be lowered for any purpose. I >>> have no idea what sort of systems VV works with - they could well be of >>> the sort where issues such as cost and timing are more important than >>> quality and reliability. >> >> There are two methodologies to consider: >> >> 1. Write a lot of code fast. Once you get a clean compile, start >> testing it on the hardware and look for bugs. Keep fixing bugs until >> it's time that you have to ship. Intend to find the rest of the bugs >> later, which usually means when enough customers complain. >> >> 2. Write and comment the code carefully. Read through it carefully to >> look for bugs, interactions, optimizations. Fix or entirely rewrite >> anything that doesn't look right. Figure more review time than coding >> time. NOW fire it up on the hardware and test it. >> >> Method 2, done right, makes it close to impossible to ship a product >> with bugs, because most of the bugs are found before you even run the >> code. Nobody can walk up and say "we have to ship it now, we'll finish >> debugging later." >> >> Method 2 is faster, too. >> >> John >> > >Method 2 is an ideal to strive for, but it is not necessarily possible - >it depends on the project. In some cases, you know what the program is >supposed to do, you know how to do it, and you can specify, design, code >and even debug the software before you have the hardware. There's no >doubt that leads to the best software - the most reliable, and the most >maintainable. If you are making a system where you have the time, >expertise (the customer's expertise - I am taking the developer's >expertise for granted here :-), and budget to support this, then that is >great. > >But in many cases, the customer does not know what they want until you >and they have gone through several rounds of prototyping, viewing, and >re-writing. As a developer, you might need a lot of trial and error >getting software support for your hardware to work properly. Sometimes >you can do reasonable prototyping of the software in a quick and dirty >way (like a simulation on a PC) to establish what you need, just like >breadboarding to test your electronics ideas, but not always. A >"development" project is, as the name suggests, something that changes >with time. Now, I am not suggesting that Method 1 is a good thing - >just that your two methods are black and white, while reality is often >somewhat grey. What do you do when a customer is asking for a control >system for a new machine he is designing, but is not really sure how it >should work? Maybe the mechanics are not finished - maybe they can't be >finished until the software is also in place. You go through a lot of >cycles of rough specification, rough design, rough coding, rough testing >with the customer, and repeat as needed. Theoretically, you could then >take the finished system, see what it does, write a specification based >on that, and re-do the software from scratch to that specification using >Method 2 above. If the machine in question is a jet engine, then that's >a very good idea - if it is an automatic rose picker, then it's unlikely >that the budget will stretch. > >I think a factor that makes us appear to have different opinions here is >the question of who is the customer. For most of my projects, we make >electronics and software for a manufacturer who builds it into their >system and sells it on to end users. You, I believe, specify and design >your own products which you then sell to end users. From our point of >view, you are your own customers. It is up to the customer (i.e., the >person who knows what the product should do) to give good >specifications. As a producer of high-end technical products, you might >be able to give such good specifications - for many developers, their >customers are their company's marketing droids or external customers, >and they don't have the required experience. > >Programming from specifications is like walking on water - it's easy >when it's frozen. There's no doubt that the task to be performed may change; it usually does. But that doesn't mean you have to use Method 1 on whatever code is changed. On the contrary, the easiest way to create bugs is to dash off quick changes without taking into account the entire context and interactions. A change in the spec is no excuse for abandoning careful coding practices. What we do is write the manual first, and get the customer to agree that's what he wants, and use the manual as our design spec. Changes may still happen, but the mechanism is to edit the manual and get agreement again, then change the code. Carefully, without hacks. And, when we're done, we have a manual! >As a developer, you can do >the best you can with the material you have - but don't promise perfection! The surest way to have bugs is to assume their inevitability. We expect, from ourselves, perfect, bug-free code, and tell our customers that they can expect bug-free products from us. When people say "all software has bugs" it really means that *their* software has bugs. John
From: Roberto Waltman on 8 Feb 2007 12:27
"rickman" wrote: >Roberto Waltman wrote: >> "rickman" wrote: >> >If C had an easy way to interactively test routines as they were >> >written, I would say C was the clear winner (no stack to fuss with). >> >> Your wish has been granted: >> >> http://www.softintegration.com/products/chstandard/ >> >> There are (were?) a few other more or less completed C interpreters. >> From memory, (not time to search now,) there was one included with >> CERN's Root project, the UPS debugger, Instant-C mentioned elsethread, >> etc. > >Looks great, but I don't see any indication that this supports an >embedded target unless that target runs Windows or similar. I've got >64 kB of Flash and 8 kB of RAM. That's correct, I missed the point on being embeddable. Still, I used it for a while (Linux version) and found it useful to quickly write and debug small programs, (that could then be recompiled for an embedded target.) >At present, Ch runs in the following operating systems: >Windows 95/98/Me/NT/2000/XP/2003 >Solaris 2.6 or above >HP-UX 10.20 or above >Linux on Intel architectuer (kernel 2.4.20-8 or above) >LinuxPPC on Power architecture (kernel 2.6.10-1 or above) >Mac OS X 10.3 or above >FreeBSD 5.1 or above >QNX 6.3.0 > >Disk space requirement for SoftIntegration Ch Standard Edtion: >40 Mb Roberto Waltman [ Please reply to the group, return address is invalid ] |