another bizarre architecture
in [Embedded]
|
From: Rich Grise on 8 Feb 2007 18:50 On Thu, 08 Feb 2007 15:34:45 -0800, John Larkin wrote: > No, but I almost ripped a ship off the dock at Avondale Shipyards, on > the Mississippi. I got it up to almost 60 RPM while tweaking a > nonlinear function generator (120 RPM is full power.) Tim the Toolman Taylor all over! ;-D ;-D ;-D Thanks! Rich
From: joseph2k on 8 Feb 2007 21:26 John Larkin wrote: > On Mon, 05 Feb 2007 18:04:43 GMT, Rich Grise <rich(a)example.net> wrote: > >>On Sat, 03 Feb 2007 22:37:05 -0500, Robert Adsett wrote: >> >>> Indeed, especially since some people have been known to produce >>> functions that look like the standard functions but are either >>> incomplete or behave slightly differently. (maybe we can call those >>> homonym functions?) >> >>In C++, that's called "Overloading". >> >>If John thinks plain ol' C is "ugly", we should protect him from ever >>seeing any C++ - He'd get apoplexy! ;-) >> >>I disagree that C is "ugly", but as they say, "de gustibus non disputandum >>est." (no accounting for taste.) :-) >> >>But, even though there are uglier languages, I can see John's point - >>from a hardware/assembly-level guy's POV, the 68xxx have always been >>very pleasant to work with. I don't know exactly where it goes on the >>"prettiness" scale, however. :-) >> >>Cheers! >>Rich > > > The PDP-11 was stunningly beautiful in its cleanliness and symmetry. > The preferred radix was octal, and the instruction set and addressing > modes fit perfectly into octal digits. I can still assemble a bit from > memory... > > 123722 = add byte, source absolute address, destination indirect > register 2, autoincrement > > Its instruction set was the basis for C. 68K has more registers and is > a 32-bit machine, but is less orthogonal and nothing you can easily > assemble from memory. Only its MOVE instruction has the > source/destination symmetry that nearly all PDP-11 opcodes had. > > John I suspect you would have likes the NS32000, 32 bit, 16 registers, hex assembly, near perfect instruction set symmetry. real purty in my book. -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens. --Schiller
From: joseph2k on 8 Feb 2007 21:34 Terry Given wrote: > Rich Grise wrote: >> On Tue, 06 Feb 2007 03:25:28 +0000, Ken Smith wrote: >> >>>Rich Grise <rich(a)example.net> wrote: >>>[....] >>> >>>>The worst are comments that don't tell you anything, usually caused by >>>>some supervisor ordering a bunch of code grunts, "Your code WILL be >>>>commented!" and you get this: >>>> >>>>LABEL1: MOV BP,SP ; move the contents of the stack pointer to the base >>>>; pointer register >>> >>>Many years ago, a friend of mine made a nice little joke program. You >>>could feed uncommented code into it and it would produce code with very >>>nice comments. It would look at two instructions and look up phrases >>>based on them and the random number generator. You knew you were in >>>trouble when they seemed to be making sense. >>> >> >> >> I once wrote a "poetry generator" which did pretty much the same - random >> noun, random verb, random adverb, random adjective, and so on. It came >> out kind of like Haiku, but some of the results were kind of spooky. ;-) >> >> Cheers! >> Rich >> > > years ago at uni, we had to do a C code metric for a group project. > turns out its kinda impossible to do properly thanks to the > pre-processor (its easy to bollocks up code that way), but we counted > lines of comments, and used an X-bar-R chart to measure their > distribution, figuring that dispersed comments are probably better than > a single essay at the beginning. > > Cheers > Terry I do some of each, at the top i document the interface restrictions. In the code i document the algorithms. -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens. --Schiller
From: Colin Paul Gloster on 9 Feb 2007 04:48 Vladimir Vassilevsky wrote: "[..] Deadlines. That's another reason for the software to be the far from perfect. [..]" John Larkin replied: "So, you will actually release software that you know is buggy, or that you haven't tested, because of some schedule? [..]" In 2001 I learnt that the Rosetta spacecraft of the European Space Agency ( WWW.ESA.int/SPECIALS/Rosetta/ ) (which is to intercept a comet in 2014 and had still been under development in 2001) had extremely unacceptable onboard software. Someone explained to me that the software was written without a good hold on requirements and that ground testing was not indicative of what it will be doing. Rosetta was launched in 2004. A lot of updating of software was planned for the period between launch and interception as it was argued that software could be fixed during the many years when cruising. However, this attitude was partially related to a need to launch the spacecraft by a deadline so that orbits would make it feasible to reach a particular comet, a deadline which was not adhered to so Rosetta is actually cruising to a different comet than had been planned in 2001. (The cruise's duration for the original plan was nine years.) Regards, Colin Paul Gloster
From: David Brown on 9 Feb 2007 07:04
John Larkin wrote: <snip> > > I don't like interrupts. The state of a system can become > unpredictable if important events can happen at any time. A > periodically run, uninterruptable state machine has no synchronization > problems. Interrupts to, say, put serial input into a buffer, and > *one* periodic interrupt that runs all your little state blocks, are > usually safe. Something like interrupting when a switch closes can get > nasty. > > John > Interrupts should normally only be used when polling is unsuitable - either because you need fast reactions, or because you don't want to have to add polling mechanisms. I've seen programs where pressing a switch triggers an interrupt causing action such as messages on a screen, which is daft. The person pressing the switch will not notice the delay polling would cause, it completely messes up the timing of important interrupts, and can cause conflicts between the main program loop (which may be writing to the screen at the time). Very bad. On the other hand, I often use a software timer setup where program modules can register a function to be called regularly in the background. When the hardware timer underlying this system times out, it's interrupt handler calls all the pending software timer functions after first re-enabling interrupts. In this way, I can have predictable periodic functions that may take significant run time (though less than a timer tick in total) without affecting fast interrupts, and without having to be polled in the main loop. Of course, sometimes the timer function merely sets a flag that *is* polled in the main loop - it depends on the situation. I've even had programs where the main loop is nothing but a "sleep" instruction, with everything handled in interrupts this way. |