Author Topic: how do you debug the code?  (Read 15924 times)

0 Members and 1 Guest are viewing this topic.

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: how do you debug the code?
« Reply #100 on: June 22, 2022, 08:08:45 pm »
debugging is something you need a human to do
Sure, A.I.ICEs don't understand humans.
Rather, programming languages are still the best tool we have for conveying human intent to nonhuman processors.

If we had anything better to convey the intent, then we could write a compiler that generated code that we intended, instead of code that we wrote.  But we don't, so we can't.

That's actually a more general question: languages in general!

We have indeed found nothing better, over the course of humankind, than languages to convey our intents to others.
The question of *why* we would want to use any other way is in itself both fascinating and concerning.

A language (be it natural or programming) is a tool to express what's happening inside our brain without the other party having to "guess" what it is.

But are we becoming so "lazy" that languages are now becoming too much of a burden?

 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: how do you debug the code?
« Reply #101 on: June 22, 2022, 08:23:53 pm »
By assumptions, I mean we all make them.

Yes. What you meant by that was clear and clearly understood.

Otherwise we would write perfectly generic code which would solve all the problems in the Universe.

No we wouldn't. Or if we do, maybe that should look like:
Code: [Select]
42;
But real code has built-in assumptions


Real code is code we write. It has the built-in assumptions you choose to build in. It's either a deliberate choice (in which case you better make sure your assumptions hold), or an overlook (which is not great, but we're all human.)

such as number_of_samples needs to be an even number, because that's obvious to anyone who understands the particular algorithm, right? But still, maybe your configuration bus corrupts a value every now and then. Or someone does not understand the algorithm. Or you realize down the road that odd number_of_samples would make sense after all and forgot about the hidden assumption. Make it explicit by assert(), because the other option would be to write another algorithm for odd values which could take too much design time. But an error check is way cheaper!

Make this a habit:

 instead of / in addition to:
// n_samples must be even
write:
assert(n_samples % 2 == 0);

And of course,
assert(n_samples >= 0 && n_samples <= NUM_ELEMS(sample_tbl)); // where #define NUM_ELEMS(arr) (sizeof((arr))/sizeof((arr)[0]))

Your example is a simple, yet perfect example of what I'm saying. If n_samples must be even and you have no means of ensuring it in a reasonably proven way, check that it is, which is what you're doing above.

All I'm saying on top of that is an extra point about assertions (and Hoare did agree with me there) and how I usually favor run-time tests at all times, unless again in specific, documented cases for which it is unpractical (which are relatively rare in practice.)

I know this isn't a very popular approach, except in safety-critical software. I'm just expressing my take on it. Everyone's free to agree, disagree or go fishing. =)
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: how do you debug the code?
« Reply #102 on: June 22, 2022, 08:27:40 pm »
All I'm saying on top of that is an extra point about assertions (and Hoare did agree with me there) and how I usually favor run-time tests at all times, unless again in specific, documented cases for which it is unpractical (which are relatively rare in practice.)

I know this isn't a very popular approach, except in safety-critical software. I'm just expressing my take on it. Everyone's free to agree, disagree or go fishing. =)
Tests like these also make it possible to work on projects with less experienced programmers. In one of my recent projects I spend a couple of hours to include a mechanism that checks whether a mutex for an I2C bus is locked before use (why this is necessary is a long and sad story). It is easy to forget to lock a mutex but the consequences can be severe. With the check in place the program crashes with a clear error message.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: how do you debug the code?
« Reply #103 on: June 22, 2022, 08:42:13 pm »
All I'm saying on top of that is an extra point about assertions (and Hoare did agree with me there) and how I usually favor run-time tests at all times, unless again in specific, documented cases for which it is unpractical (which are relatively rare in practice.)

I know this isn't a very popular approach, except in safety-critical software. I'm just expressing my take on it. Everyone's free to agree, disagree or go fishing. =)
Tests like these also make it possible to work on projects with less experienced programmers. In one of my recent projects I spend a couple of hours to include a mechanism that checks whether a mutex for an I2C bus is locked before use (why this is necessary is a long and sad story). It is easy to forget to lock a mutex but the consequences can be severe. With the check in place the program crashes with a clear error message.

One of the reasons, and rationale, for not doing it, that I've heard the most, is not about the testing at run-time itself (except again when the cost in terms of timing would be unacceptable), but mostly all about error handling.

The most common claim is something like (and I'm sure many people reading this thread would say the same): "ok, but what will you do if the test fails?"

Many people assume that if something that "shouldn't" fail in software in normal circumstances, fails, then there's generally nothing you can do anyway, and then better pray or let the whole thing crash. As there is nothing reasonable we can do about it, right?

It all depends on the context of course - there is again no silver bullet and unique answer to every case.
But handling errors gracefully is possible in a surprisingly large number of cases in reality. It does require some thinking and some extra work though, no doubt about it.

The question to ask is simple: "if this test fails, what should the system do that would cause the least harm/surprise the user the least/allow the system to get back on track/etc. ?"
There's almost always an answer to this one. Even if, say, in a particular case, some test failing would be unrecoverable and would require a system reset: then I'll favor handling it explicitely and calling whatever will explicitely reset the system - in the cleanest way it can - rather than just let code execute and do whatever until the system may encounter a hard fault and reset on its own.

Again, the context matters. Those are just general rules. There may be exceptions here and there. My 2 cents. Take it or leave it, I'm not even saying this is what *you* should be doing, I'm just saying that's what I do and what I tend to promote if my advice is being requested.
 

Online tellurium

  • Regular Contributor
  • *
  • Posts: 226
  • Country: ua
Re: how do you debug the code?
« Reply #104 on: June 22, 2022, 08:54:28 pm »
if you exist and you are self-aware, good news, you are already in for free! ... the problem is what happen when you stop to exist? Nobody knows. Where your where does your conscience goes? your body can be recycled, but what about your conscience? it's a complex problem, and nobody can describe what exactly is "consciousness

So much for printf debugging :)
Open source embedded network library https://mongoose.ws
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 
The following users thanked this post: SiliconWizard, DiTBho

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: how do you debug the code?
« Reply #105 on: June 22, 2022, 09:14:15 pm »
yup i dont have ice the hardware.. only a cloned isp mk2 :P if it can tells me where a recent interrupt routine.. interrupted my code (at machine/assembly/c level), maybe i should put some effort to get one?

Can't remember, sorry. Typically they will try to ignore interrupts (otherwise it's a right pain stepping non-interrupt code), but I reckon you could put a breakpoint in the ISR and then see where the return gets you to. Often that's a library function and not awfully useful, though :)
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: how do you debug the code?
« Reply #106 on: June 22, 2022, 09:16:51 pm »
So much for printf debugging :)

I suppose, debugging a program/computer with printf's, is a bit like a sobriety test for humans.   ;)   ;)   ;)
 
The following users thanked this post: DiTBho, tellurium, Kittu20

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3796
  • Country: gb
Re: how do you debug the code?
« Reply #107 on: June 22, 2022, 09:33:45 pm »
If you can debug with printf, you can prove to your consciousness that you exist!  ;D
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 
The following users thanked this post: MK14

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: how do you debug the code?
« Reply #108 on: June 22, 2022, 09:53:06 pm »
If you can debug with printf, you can prove to your consciousness that you exist!  ;D
if you can be debugged with a printf you must be a  small routine in a simple system.  >:D . careful, some script kiddie may replace you with a very small script , written in java , running in an x86 emulator on top of an Apple M1 ... also known as two million lines of code, 20 billion transistors to toggle a boolean...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 
The following users thanked this post: DiTBho

Offline Smokey

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Not An Expert
Re: how do you debug the code?
« Reply #109 on: June 22, 2022, 10:47:37 pm »
Another thing to be aware of...

I'm currently doing a design with Bluetooth for the first time (Cortex-M0 SoC).  I've found that if you set a breakpoint in the debugger while there is an active BLE connection, the connected device will timeout and disconnect.  So breakpoints to debug stuff related to BLE isn't an option (please tell me I'm wrong if I'm just missing something).
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: how do you debug the code?
« Reply #110 on: June 22, 2022, 11:58:36 pm »
Quote
So breakpoints to debug stuff related to BLE isn't an option

That's not BLE-specific - anything that's externally time sensitive will have an issue when the related code is stopped at a breakpoint.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: how do you debug the code?
« Reply #111 on: June 23, 2022, 12:32:32 am »
Another thing to be aware of...

I'm currently doing a design with Bluetooth for the first time (Cortex-M0 SoC).  I've found that if you set a breakpoint in the debugger while there is an active BLE connection, the connected device will timeout and disconnect.  So breakpoints to debug stuff related to BLE isn't an option (please tell me I'm wrong if I'm just missing something).
that's because the hardware needs the firmware to run and service interrupts. There are background processes. if you are trapped on break those processes are also stopped.
That's where a real ICE / trace comes in. you can snapshot the state WITHOUT stopping the target. This is done through the ETM and PTM modules. Modern processors like Cortex, Risc-V , ARC all have hardware assisted debugging. It's like a mini logic analyser. You set up the conditions and when it fires it can make a snapshot. this is then loaded into your IDE and you can work at sourcelevel.

that's why debugging with printf is like mowing the lawn by plucking one strand at a time with tweezers and telling everyone else to stay off the grass while you are doing it..
« Last Edit: June 23, 2022, 12:39:04 am by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 
The following users thanked this post: MK14

Offline Doctorandus_P

  • Super Contributor
  • ***
  • Posts: 3321
  • Country: nl
Re: how do you debug the code?
« Reply #112 on: June 23, 2022, 01:06:39 am »
What is your general approach for any compiler to c debug code ?

There is no "general approach". You have to match the method to the problem.

If it's some general algorithm, I usually firs write the code as a PC program and then port it to a microcontroller, as the compile and re-run cycle is easier.

printf can be handy when designing new algorithms. say you have for example a sorting algorithm, then printf can leave a trace on how it goes through the algorithm without interrupting it.

Somewhat similar, a method I like is to toggle some output pins of a micrcocontroller. I've written a few small macro's to do this and these can output 8N1 messages. Output is quick enough that I just can leave it running, and then when a program crashes I can back-track through this info in a logic analyzer and also correlate it with other I/O that is captured. The code is small and quick enough that I can even use it in ISR's to monitor how the ISR is functioning (I have used it in an ISR with about 6 if() statements and even a goto to reset some states under specific data faults.

I once had a nasty bug but could not find motivation to fix it. After about a year I made a big pot of coffee, and just started reading source code. Big sections of the code were very easy to read (thanks to maintenance and refactoring) and could therefore be quickly dismissed. In C & C++ pointers are always suspicious, especially with not very experienced programmers (that was me at that time) and I knew that, so I paid extra attention to each pointer I saw. In the end it was a pointer to a local but non static variable in an ISR and I found it in a few hours.

My most nasty bug ever was at work. It was for a (then quite big)16-bit microcontroller with a MB of flash. I spend approximately 7 work days guessing at parts of code that could be deleted (It was an RTOS system with 30+ tasks running) and I managed to remove about 95% of all code in that week and a half before I got stuck and had to hand it over to a more experienced colleague. It took him another two days, including use of a logic analyzer to find the bug. It turned out to be a 16 bit pointer with a too small range so it wrapped around when it should not, and that bug was "fixed" by changing a compiler flag in the GUI.

I already mentioned it briefly, but refactoring sections of dubiously written code is an important debugging technique. Instead of trying to fix the mess afterwards, preventing it from going awry in the first place is much better. So even before refactoring (duing maintenance) you have the initial high level design of the code.

I've had a bit of toe dipped in unit testing. I quite like the idea of writing both tests and code at the same time. In one of my experiments I was learning some Python (a quite atrocious language with horrible whitespace depencency and no variable declarations, so it just "invents" new variables on a simple typo, and it does not compile so even checking if all code is even executable is a nasty exercise. /rant) In the end I had a unit test function that simulated input of about 20 packets sent over a network (and thus got fragmented etc) and those got re-assembled and processed, and the processed output was captured once and thereafter could be used to test if the whole unit still worked after further modifications, and this all worked quite nicely.
« Last Edit: June 23, 2022, 01:28:01 am by Doctorandus_P »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: how do you debug the code?
« Reply #113 on: June 23, 2022, 01:44:55 am »
if you can be debugged with a printf you must be a  small routine in a simple system.

In fact it's the exact opposite.

Student programs can be debugged with breakpoints and single-stepping. Large complex systems demand printf and external automated analysis of the resulting MBs or GBs log file. You wouldn't live long enough to stop at a breakpoint at every one of the millions of times a printf logs to the file, let alone to make a meaningful examination of variables at that point.
 
The following users thanked this post: nctnico, Siwastaja

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: how do you debug the code?
« Reply #114 on: June 23, 2022, 07:13:00 am »
Quote
So breakpoints to debug stuff related to BLE isn't an option

That's not BLE-specific - anything that's externally time sensitive will have an issue when the related code is stopped at a breakpoint.

Now here's the thing. Let's say you have a software-controlled motor inverter or DC/DC converter. You just can't stop the program at arbitrary point, or you blow up things (semiconductors, physical things attached to motor axle, whatever).

Now you are lost trying to find some nasty bug, and the only way you seem to have is to add breakpoint in the middle of critical handler and examine internal state, for whatever reason.

The options are:
1) Add a breakpoint in debugger.

Consequence: when it is hit, all hell breaks loose.

2) Write an error handler which does safe shutdown, by doing the necessary GPIO writes to turn MOSFETs off, turn mechanical brake on, whatever is needed.

Instead of adding a BKPT, you just add call to this error handler. You achieve the same: program stops here. Difference is, it now happens safely, as defined by you.

Now you totally can use #2 to stop the system, and then attach debugger probe to continue examining the state. This is combination of manual code intervention and using the general purpose debugger.

But the thing is, once you have had to write your own handler manually anyway, why not improve it to log the state of interest? This will then break the dependency of having to rarely attach a debugger. Your workflow is simplified. This is because you can't avoid manual instrumentation anyway, so why not make good use of it.

There is also option 3), sometimes peripherals such as motor control timers have special hardware logic so that when the debugger halts the CPU core, you can also halt the timer plus make the outputs go to some predefined IDLE state.

But quite frankly, this seems like a made-up response by the manufacturer to the criticism that breakpointing critical control code is impossible. But the problem isn't properly solved: you still only can make the particular timer module go in safe state, but likely this isn't enough, you would want to toggle a GPIO, maybe with a delay, whatever is needed for completely safe state. Can't automate everything through the peripheral. And then, finally, you need to configure this debug mechanism in code. So you can't avoid modifying code for debugging purposes, after all.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: how do you debug the code?
« Reply #115 on: June 23, 2022, 07:16:19 am »
You wouldn't live long enough to stop at a breakpoint at every one of the millions of times a printf logs to the file

You also wouldn't live long enough to read through all those millions of printf's.  So, if you can automate sifting through those printf's, because of criterion of detecting the bug situation.  E.g. a variable has exceeded 1,000.  Then a powerful enough debugger, could be set to the appropriate, conditional breakpoint(s).  To similarly find the bug locations and hence fix the situation.

Both printf's and debuggers, both have their uses, and hence pros and cons.  But to suggest that one particular method is THE method, isn't taking into account the thousands or even millions or more, of different circumstances (hardware, programming language, experience level, requirements, budgets, timescales,  etc).  One or more of which, can favor one method over others.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: how do you debug the code?
« Reply #116 on: June 23, 2022, 07:17:36 am »
Student programs can be debugged with breakpoints and single-stepping. Large complex systems demand printf and external automated analysis of the resulting MBs or GBs log file. You wouldn't live long enough to stop at a breakpoint at every one of the millions of times a printf logs to the file, let alone to make a meaningful examination of variables at that point.

This, and relatively easy to use but powerful tools like Excel/Libreoffice & Matlab/Octave are hugely useful for analyzing .csv logs. Especially if you have a system that measures or controls any "analog" parameter say acceleration or current, or has PID control loops or whatever.
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: how do you debug the code?
« Reply #117 on: June 23, 2022, 10:21:30 am »
Quote
So breakpoints to debug stuff related to BLE isn't an option

That's not BLE-specific - anything that's externally time sensitive will have an issue when the related code is stopped at a breakpoint.

Now here's the thing. Let's say you have a software-controlled motor inverter or DC/DC converter. You just can't stop the program at arbitrary point, or you blow up things (semiconductors, physical things attached to motor axle, whatever).

This is going to go nowhere because we are polarised and arguing extremes. The points you raise are perfectly good but biases towards having a downer on ICE. Not everyone will be controlling a motor inverter and often it doesn't matter at all if halting kills the system - at that point you'll have discovered what you need to. It is also quite a bit fast than compiling, never mind writing some code (after figuring out what to write) beforehand.

In practise, having access to ICE features doesn't mean you're going to use them exclusively. The actual problem, and one's assumption as to likely cause, will determine which tool is better suited. Sometimes a combination: a breakpoint tripping (or not!) might indicate the route to the fault, and then printfs show why it took that route. Conversely, plastering printfs over some function might still miss the important bit and a breakpoint on the printf will allow quick examination of something slipping through the gaps.

But just as one doesn't get the best out of a screwdriver by using it as a hammer, a knowledge of the capabilities and use of debugging tools is important, and then the appropriate one can be chosen at the time. Of course, someone will favour one tool over another, and someone else wil prefer a different tool. Neither is 'wrong' if it works for them - in the end, fixing the problem is what matters, not so much what was used to get there.

In the context of this thread, I think it would be more useful to a beginner to know how to use the various options, so he can build enough knowledge to make up his own mind, rather than being told such and such is shit and absolutely the wrong thing to do. Think about C goto's and  how many beginners think they are spawn of the devil and any code with them in is by definition complete rubbish. But they have their place, and only by learning how to use them can one realise what that place is.

 
The following users thanked this post: MK14

Online voltsandjolts

  • Supporter
  • ****
  • Posts: 2277
  • Country: gb
Re: how do you debug the code?
« Reply #118 on: June 23, 2022, 10:43:33 am »
Let's not argue over who killed who ;D

It's interesting to read this thread and see the various debug techniques you all use, all have their uses. Being aware of all the options is the important point, so you can make an informed decision on which best suits you, the task at hand and the available tools.

Happy debugging to all 8)
 
The following users thanked this post: MK14

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: how do you debug the code?
« Reply #119 on: June 23, 2022, 12:50:26 pm »

Happy debugging to all 8)
no, debugging is for beginners. The real greybeards directly make the mask for an expensive mask rom and it works first time !
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 
The following users thanked this post: Bassman59

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: how do you debug the code?
« Reply #120 on: June 23, 2022, 01:37:28 pm »
It's a funny joke sure, but actually I have been starting to question the idea that all software will definitely have a lot of bugs and ironing them out takes a lot of effort.

I mean, I have been going up from the Dunning-Kruger valley of despair, maybe I was there 15-10 years ago.

During last 2-3 years, I have some weird experiences, like this one: I wrote quite a complex embedded communication system thingie in one go, something like 1000LoC. I know past myself, and I think it would have been a month of more-or-less painful iteration to write and test it.

Now writing the code felt somehow different than it used to: my code output was slower. So it took like 4-5 days to finish the whole large submodule. Then I compiled it for the first time. Fixed a few typos. Compiled again. Flashed on the chip. Wakes up and seems to work. Try a few test vectors. Everything seems to work in first go. Test more thoroughly. Find a bug that automagically prints error code, spend 1 minute fixing the bug. Voila, it's now in production. It's still in production after a few months, no problems with that piece. I have never had such low bug rate before in such medium complexity project.

I'm not saying there won't be any bugs. But I am saying I do not consider myself world-class programmer expert, I consider myself someone who have left the Valley Of Despair a long time ago but is still far from the Plateau of Sustainability. I'm sure many on this forum are way better and more careful programmers than I am. I'm still not capable of doing that every time and something still drives me to occasionally write beginner level crap I don't like and which causes colossal pain, but having a few experiences like this gives me hope, and it's a sign I'm on the right track.

This makes me truly feel it is completely humanly possible to write almost bug-free code, which, coupled with integrated-from-day-one instrumentation, means very very very little of those painful debugging sessions.

I like Nominal Animal's "eyeball mk II" metaphor; I know some will take it as a joke, but I suggest you take it seriously. Debugging is difficult and slow, avoiding bugs by understanding what code you write and why is a true and actual possibility.
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11534
  • Country: my
  • reassessing directives...
Re: how do you debug the code?
« Reply #121 on: June 23, 2022, 02:20:20 pm »
Happy debugging to all 8)
no, debugging is for beginners. The real greybeards directly make the mask for an expensive mask rom and it works first time !
and why the beard is grey?
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: how do you debug the code?
« Reply #122 on: June 23, 2022, 03:53:57 pm »
Happy debugging to all 8)
no, debugging is for beginners. The real greybeards directly make the mask for an expensive mask rom and it works first time !
and why the beard is grey?
experience. all the best programmers are old.
- They wrote cobol on an ibm360 and that software is STILL in use today. I wonder what is the lifespan of todays software before a new version comes out with bugfixes... weeks ? days ?
- They could toggle in bootloaders using switches. Now bootloaders don't even fit on a single floppy anymore.
- They watched the blinkenlights on the front of the machine to know the state of the computer. Sometimes they hooked up four resistors to make a crude dac and play Beethoven's fifth using idle cycles while crunching massive amounts of data and serving hundreds of users over 75 baud links at a breakneck clock speed of 750kilohertz.
- their harddisks were still hard disks. none of that solid state or 2.5 inch stuff. they were belt driven from an ac motor and used a real air compressor to make the heads float. There was one head for all platters (ramac). the size was not measured in megabytes but cubic feet and psi of (raised) floor load.
- they used pencil and paper to hand draw logic diagrams and build supercomputers (Cray)
- they landed a man on the moon with nothing but a bunch of nor gates and some software
- They knew what error 1201 and 1202 meant and the machine could safely shed processes without crashing in flames (literally)
- they would never be caught using printf to debug. There was no printf , or C or unix. they had rollers and lights to examine the entire processor state. they would single-step through the program and alter machine state at will. they could go anywhere and poke at anything.
- they knew which of the 9000 vacuum tubes to replace if the machine failed. now we just hotswap the entire damn thing.
- the power of their computer was measured in kilowatts (electric) and btu (cooling) not in megaflops.
- they had full blown shared file systems, remote networking, ethernet, email , graphical user interfaces with movable and sizeable windows, laserprinters , mice, wysiwyg .. all on a box with nothing but 74 series TTL ic's. the damn thing didn't have a processor, or bit slice. it had 74181 alu's ! (Xerox Alto). those alu's didn't even have flipflops. they were just a bunch of and and nor gates

now we have machines that have a million times more memory, run 5000 times faster , have 60 times the amount of processors and what do we do ? we bolt a virtual machine on the hardware , emulate a different system , plonk java or python on it and then debug the code with .. printf (or equivalent) . ... we've lost it , completely. There is no more hope. We might as well pack it in and stop software development altogether. there is zero chance to make anything that is bug-free
« Last Edit: June 23, 2022, 04:09:59 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 
The following users thanked this post: MK14, BrokenYugo

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: gb
    • Me
Re: how do you debug the code?
« Reply #123 on: June 23, 2022, 04:41:22 pm »
If you are old enough to have learnt programming in an environment where you wrote your program on a coding sheet, it was typed (by someone else) onto punched cards, and submitted as a batch job whose output you got the following day, you realised in those days that relying on debugging was never going to get a non-trivial program completed. Instead, you learnt to write correct code in the first place. :box:
 
The following users thanked this post: Siwastaja

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11534
  • Country: my
  • reassessing directives...
Re: how do you debug the code?
« Reply #124 on: June 23, 2022, 04:43:59 pm »
man, jtag is not even mentioned in the list! do you mean all the best people extinct? who greybearded uses cobol nowadays? all the glorious stories told without mentioning the hardworks and experienced gained during the "debugging" stage of life. you dont expect greybearded just came out of a womb in an instance right? btw... talking about "the best men" they do still exist... its just "politics" more and more get in the way... i just spent sometime few days ago reading about Perelman's Incident.. he still live and probably in exile... even if you can meet him i believe it will not be a good experience talking with heavy left-brained person...

]t

on to something about semiconductor debugging...
https://semiengineering.com/knowledge_centers/eda-design/verification/debug/

Instead, you learnt to write correct code in the first place. :box:
thats called debugging in your head. probably was common before the invention of turing complete universal machine (computer) with "if" and "branch"
« Last Edit: June 23, 2022, 05:29:37 pm by Mechatrommer »
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf