Disobeying jet engines - why?

If you use state machines, and don't multitask, you don't need semaphores. If you don't allocate resources, you can't have deadlocks.

It's simple.

Programmers want that fancy stuff on their resumes.

Umm, I should have my head examined. Twice.

John

On a sunny day (Wed, 30 Jan 2008 07:08:01 -0800) it happened John Larkin wrote in :

Hey, John, I agree. Did not want to comment at first, and that is especially about debug. If you know your code, then you need no debugger! HIGH LEVEL LANGUAGES LIKE HEX or ASM need no debugger (I ain't kidding). Most I will do in huge programs in C (C++ is not really a language but a disability, Stroussup did not know how to program, and that is why he created C++), is add some printf() statements. In ASM, or programming in binary, you should know what happens from what you get. Honestly last time I used a debugger was in 1983? They tried to sell me all sorts of stuff, ICE, hell, you should be able to understand what is going on from what happens. Many people seem to have an attention span of about ehhh 7 minutes? So they cannot follow any code, especially as the spaghetti they wrote probably has that knot after 7 minutes, then they spend hours looking in a debugger, to find that bit that flipped, which it should have, as they programmed the knot.

LOL So lets see , somebody is going to byte.

To understand C++, you have to be a "real programmer", or a physicist.

True, but you can do same things with C as in ASM. A debugger is a good friend, if your code is hell complicated. ASM is really simple. It is good for simple things. But I wouldn't use ASM to implement floating point arithmetic.

-- Levente

C++),

get.

knot.

I program embedded stuff in assembly, but I do usually have to "debug" a new design. I use a nice 11x14" fanfold listing, fully commented, and a laptop pc with a PE Micro background debug pod. I unplug the application eprom and plug in a ram adapter, then load the code through the BDM. That lets me examine/patch memory, set breakpoints, step code, diddle ports, whatever. I also measure execution times of interesting routines and add them to the comments in the listing.

Sometimes a big hunk of code, dozens or hundreds of lines, just works the first time, and sometimes there are silly, dumb mistakes. Sometimes the hardware doesn't work as expected, like the serial DAC that has to be clocked one more time than the datasheet suggests.

We are also integrating the uP code with as many as six Xilinx fpga's (which are configured by the code), an Ethernet adapter, sometimes a user interface, and all sorts of sundry junk. For all of this to work at powerup is rare, although it does happen now and then.

It does seem like, once the fundamental stuff is up and running, there comes a point where just observing system behavior is sufficient to spot bugs and lead you to the right part of the source code to fix it.

I figure we spend way under 10% of a project's time debugging the hardware and firmware, not enough to motivate more sophisticated tools. Manuals and test sets/procedures are much bigger problems.

John

Well you do need a debugger above a certain code complexity allright. I am well past my 1M lines of code (no C junk), and even though I "live" in an environment 100% my doing - debuggers, assemblers/ compilers, OS, you name it - I do need a debugger pretty often. One makes mistakes, there are unknown/unexpected things in the behaviour of this or that etc.

Here is a typical picture (I did it only to show what it looks like, recently I was debugging this, it is ready now :-) :

The debugger seen through the "terminal" window is running on the same CPU in this case. Sometimes it is a remote device. I also usually keep a number of shell (DPS shell, that is) windows open and mess around with whatever has to be messed around from some of them...

Dimiter

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

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

eated C++),

ou get.

bably

e knot.

On a sunny day (Wed, 30 Jan 2008 17:37:37 +0100) it happened Levente wrote in :

Well I hope I will never be :-) 'real programmer, 12 guys in an IT department doing data-beast things, getting payed 100k / year? while the whole thing could be done perhaps by one man who was a simple programmer.

Long time ago, (say 1983 for that matter) I did read a paper from uni Twenthe Netherlands, about why a debugger should not be used for high level languages like C. I agreed, and do not use one. I do trust the compiler, and in very exceptional cases will look up the asm it generates.

It is a simple as you make it.

Well I have that asm float lib here, it is not THAT bad. In embedded, space may be an issue, I do not like C on embedded with unsuitable memory size like PIC16 etc, float or not.

On a sunny day (Wed, 30 Jan 2008 08:44:17 -0800) it happened John Larkin wrote in :

On a sunny day (Wed, 30 Jan 2008 09:16:30 -0800 (PST)) it happened Didi wrote in :

I do not see this, honestly. I do the complicated stuff in Linux, not sure if I did hit the 1M lines of code, way over 100000 I am in some programs though. I mean gdb is just 3 characters away, but in C printf() always helps me out.

There are some basic rules, and libc.info is my friend, gives me all the help I need, and prevents me from doing things better not done. And I try to avoid exotic constructs. In C: keep your pointers in range, check for null pointers in every function.

t.

Oh in C (or Basic or whatever HLL) using the debugger is not much use, I agree.

But I was talking programming, not rearranging someone elses code :-).

I do not take seriously any embedded thing written in C or any HLL for that. If they use it (as I am sure thay do) on jets like in this thread, we can only expect more disobeying engines and anything.

The main thing HLLs do is hide the CPU details from the programmer. If the CPU is too ugly to program (most are...) with its details in sight, pick another CPU, there are options. If that does not help, well, one should consider another job...

Dimiter

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

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

t.

elp

on.

Well, I'm doing better than that now, but as far as making the big bucks, I can probably tell you 12 ways not to become an entrepreneur. ;-) (cf. Edison re 999 ways not to make a lightbulb. ;-) )

Cheers! Rich

On a sunny day (Wed, 30 Jan 2008 10:28:23 -0800 (PST)) it happened Didi wrote in :

eh, using C, with the modern compilers highly optimising, they 'know' the processor', may actually improve performance, and reduce chances of errors that could have occurred by misunderstanding some CPU features by an asm programmer. Lots of stuff is in C, my Linksys wireless access point for example. It is open source, runs Linux, and is in fact a small computer. No way would I dream of writing all that in asm. Its reliable, been up for weeks now... (since I last accidently switched it off).

I dunno, it is not the language, it is the coding that makes a difference. It is true that you lose some control in C, but if the libraries are OK, then it saves you a LOT of time.

Much is 'vague', for example if you use FPGA, then you depend on the vendor's soft to create the interconnects from the HDL. It cannot be done by hand I think.... And some of that soft is not very good, does it mean FPGA should not be on airplanes? I'd be more worried about Xilinx webpack used for an FPGA in an airplane system then using C in the same on some micro. :-)

And, Linux has been used in satellites (all C), FPGA is in mars rover...... It is all possible.

Unfortuntaely the "windows" (not just Microsoft Windows, but also, e.g., X Windows and I would guess whatever older Macs used) paradigm makes it difficult to not fire off multiple threads for even relatively simple applications. For instance, if your serial interface API blocks for a specified timeout period (e.g., 15 seconds if no response from some serial device is heard), the GUI is going to be blocked as well for those 15 seconds and your user will at best find this behavior annoying and at worst thing your program is broken. While you could certainly argue that the guy who wrote the serial API to block on a read was a nut bag, you're then into the discussion of how much of someone else's tried and tested code you want to rip up and re-do (which may not even be possible if you're interfacing to someone else's hardware) vs. just using what's provided and still provide a "nice" user experience regardless of how bogged up the provided API is.

...because all of the "big guys" (Microsoft, Intel, HP, etc.) are ASKING FOR that "fancy stuff." So these days your average college grad is likely to have been exposed to a whole potpourri of various "cool" technologies but hasn't necessarily had time to learn any of them particularly "deeply" or even just understand how they work and thus how you'd build them from scratch if you had to.

---Joel

eated C++),

ou get.

bably

e knot.

Thank you for coming in for the interview, but we have decided to hire someone else for the position.

Something as simple as a standard CRC routine such as this one:

ULONG CalcCRC(ULONG rc,const UCHAR* buf,UINT len) { while (len > 0) { UCHAR nb = *buf; UCHAR i = (rc & 0xff); i ^= nb; rc = rc >> 8; rc ^= CRCTable [i]; buf++; len--; }

return rc; }

...is a lot quicker to implement in C than it is in assembly; if I'm paying someone to do this C is certainly the way to go here. It's also then a lot faster to change the code around to use pointers (effectively changing the addressing mode used in the generated code) and check whether or not the performance improves (on this CPU it became a little worse).

This is a good point that a lot of people overlook. Even if you're programming in assembly, you're still making use of the (seemingly reasonable, at first blush) assumption that the code will execute the way you wrote it. With superscalar CPUs that dynamically reorder program execution, that's a HUGE amount of complexity going on behind the scenes to give the _appearance_ that that's what's happening, and of course the end result is that pretty much all "big iron" (32 or 64 bit desktop) CPUs today have non-negligible errata lists of what doesn't quite work the way it should.

---Joel

features

It may, if the programmer is not up to the task. Calling some library functions using some C hyeroglyphs is a lot less demanding than writing code, this is obvious. The thing is, in order to make something useful which is not already out there you do need to write more than what the library contains; and the code people write on these occasions - where it really matters - in C is generally complete garbage. Not because the compilers are bad or the libraries etc. - mostly because the C language is crippling the programmers, too much of their mind is occupied with the hoops they have to jump through in order to produce what they need. Using a lower level language allows one to just type in a few lines more and be done with it, typically at a 10+ times better code efficiency (and at a similar coding efficiency, I would claim for myself). I have numerous things written, we can do a comparison of equivalent pieces of code if you do not just take my word :-).

Dimiter

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

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

Jan Panteltje wrote:

features

off).

soft

airplanes?

features

off).

I once had a job working on firmware for an 80186(!), that was written in "turbo assembler". ;-) When I had to code a particularly hairy routine, I wrote it in C, compiled it with MSC with the "asm listing" output, and tweaked that a little and just plopped it down in the ASM.

But, I did have to tweak it a little here and there.

Cheers! Rich

lot

So how quickly did you do it the first time? (copying, if you just found it and took it, does not count). I did it in VPA for an hour or so a few years back, see the source excerpt (for PPP, 16 bit CRC - I also have the 32 bit, obviously, which takes a few lines less, don't remember why) at

Notice that my code uses a linked list of descriptors, the data for the CRC often is spread at a number of locations. Can you produce the binary (or, better, the native machine code as I did) for your code? You say it is easy to modify it in C, so adding the level of indirection to do the gathering will not take too much, I take it. I leave it to the rest of the group to say which piece of code is easier to read and understand - and thus keep under control.

Dimiter

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

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

lot

ble,

ce_

much

:-)

No. Make a google search on real programmer. You'll see.

I usually code everything in C. From ATMEGA8 to Unix on i386. On Unix, I use gdb. Well... I think debuggers developed since 1983. :-) But, I don't like the debugger on MCUs...

-- Levente

What are going on about? Is there any other way than ASM to implement floating point? In "C" it is given to you in the math library. Same with most higher level languages. I have even seen such in native CPU instructions, and in ASM libraries for smaller CPUs.

Not on yours but on Levente's