Open Letter to Chip Gracey

Lord Steve · 2008-03-12 18:07

Dear Chip,

Could the Prop 2 please have hardware debug support?

All the best,
Steve
·

cgracey · 2008-03-12 18:59

Steve,

This would complicate the cogs somewhat. Even if we added minimal breakpoint hardware, there would still need to be some code executed within the cog to handle the higher-level breakpoint management. Maybe a shadow ROM debugger, plus some extra RAM·would be required for this to work adequately with a full-sized cog application. We put some of this stuff into the SX chip, and I'm sure once the features were documented, people started (ab)using the debugging circuitry, like the 8-byte FIFO, for their own applications, as it IS useful. In doing so, though, they forfeited·the debugging functionality. Basically, every documented resource is going to be used by application programmers, and this can undermine intended purposes of special debugging circuitry. Rather than add a real-time trace buffer to each cog, why not just give everyone more application memory? This is·the sort of dilemma we face.

I think I know what you want, though: Single-stepping, breakpoints, break on register contents, etc. A nice PC-side debugger with animated windows showing what's happening inside a cog would be ideal. Certainly, it would be a great learning tool. After that, it might become more trouble than it's worth. What I think works great is to set up application-specific mechanisms that toggle a pin or·write to a memory location. This can be a single PASM instruction which is fast and small.·A general-purpose debugger is a lot more complicated and must attempt to be a one-size-fits-all solution to what is usually an evolving time/memory-constrained problem.

Here is something that somebody could design today that could serve learning AND debugging·purposes adequately well:

Use a Propeller chip as an in-circuit dummy, while performing cog- or even chip-level simulation within the PC, while talking at 3Mpbs over the USB/serial link. Some cogs could run real applications at full speed, while others·can be simulated on the·PC, with their I/O updates coming over the USB/serial link. With the ROM code·now available, you could simulate everything, from the whole chip down to a single cog running Spin.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

ErNa · 2008-03-12 20:56

Yes, Chip, you are right. A propeller programmer will immediately state: It's not a debuger, its a feature!

Give us more memory and, if possible, just make a I/O-port, that is not pinned out, but allows communication between cogs via a parallel port.

Lord Steve · 2008-03-12 22:35

All that needs to happen is that every bit of state in the propeller is pumped out a pin on every break.· It could be a 3 megabit per second serial dump over USB and a simple state machine outside of the cogs (but linked to the cogs and hub memory) could do all the work of loading each memory location in each cog and shift it out, load each memory location in hub RAM and shift it out.· Each cog would need (a) comparator(s) for a breakpoint(s) that halt(s) the cog clock or optionally the system clock and start(s) the data streaming.

I know it's work and I understand the engineering-driven approach with the Propeller (and I like it), but I see this as a cheap-in-terms-of-silicon thing and it would more quickly open the door up to a wider audience for your baby.· Maybe I'm way wrong (I've never designed a chip before) but I feel 2·pennies lighter!· [noparse]:D[/noparse]

Correct me if I'm way off on the silicon footprint issue.

--Steve
·

Mike Green · 2008-03-12 23:05

You're asking for much more than you think. For one, the cogs function independently unless a hub operation is performed and even then the other cogs continue to operate at full speed. You would stall the entire chip for a state dump regardless of what the other cogs were doing at the time. That might actually make it harder to debug, particularly if there's a timing problem between two cogs that's causing the bug. If you were to make this a "per-cog" function, you'd need to duplicate much of the logic per-cog.

RinksCustoms · 2008-03-13 00:34

with reference to the "cheaap-in-terms-of-silicon" thing, i remember reading a post a while back - don't bother asking, the prop chip isn't the only thing with odd memory mappinng, that said something to the effect of... "there isn't any more room for memory on this die.." reffering to the die that the Propeller was designed on. There are already rumors of a gen II chip floating about, but my hackers can't find anything on that subject.

-- note: i do not make use of the services of "hackers", that was a joke.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E³ = Thought

http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.

ImageCraft · 2008-03-13 00:44

Note that as I wrote eons ago, one nice thing (that unfortunately we will not have the time to finish by V1) of Propeller C is that since it uses LMM, it's fairly easy to add debugging hook. The current design for the ICC LMM already provides for it.

rjo_ · 2008-03-13 02:59

I can't resist... sorry for being slightly off topic...

1) I was wondering if ImageCraft is publicly traded?

Note:

http://money.cnn.com/2007/05/22/news/companies/pluggedin_birger_radioshack.fortune/index.htm, just as I predicted.

If ImageCraft isn't public, this could be a magic moment for you.

2) Somewhere down the road I fully expect to see a web-based debugger for the PropII... one that doesn't require any extra memory, is probably free (supported by advertising space) and is so slick it practically writes the code and designs the circuits for you[noparse]:)[/noparse]... that's another prediction[noparse]:)[/noparse]

Sorry for the interruption.

Mike Huselton · 2008-03-13 03:02

This partially answered my question about code profiling in another thread of my own.

The answer is you have provided hooks for it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

Lord Steve · 2008-03-13 18:19

Mike Green said...
You're asking for much more than you think. For one, the cogs function independently unless a hub operation is performed and even then the other cogs continue to operate at full speed. You would stall the entire chip for a state dump regardless of what the other cogs were doing at the time. That might actually make it harder to debug, particularly if there's a timing problem between two cogs that's causing the bug. If you were to make this a "per-cog" function, you'd need to duplicate much of the logic per-cog.

The cogs do function independently, but if a person only wanted to dump the state of one cog on break, then he could.· If it·were desired·one could halt all cogs.· If it were desired one could only dump the state of the cog(s) and not hub ram.· Maybe if a single cog were stopped it would be acceptable to the person to dump the one cog state and the hub·RAM and live with the fact that other cogs will be writing portions of hub RAM as it is being dumped.··Certainly all cogs don't need to be halted if only one cog needs·a little lovin' debugigin'.· RAM requirements of the silicon are minimal since the only information that needs to be held is the 32bits of memory going out the door via serial, an N-bit address of the memory location to send, and a few bits of configuration (x8+1 per cog and the hub).· Two pins could handle the full duplex communication and from what I understand there are about three unallocated pins left on the Prop-2's pinout.· Why, those pins could be multiplexed onto the boot up pins, perhaps.

No code would need to run in-cog.· Just a state machine to drive out a few scant different types of "packets" to the host.· The cost per-cog is small (in my mind).

I would really like to see this feature.· I use the ARM9 debugger at work almost daily and the usefulness of such capabilities increases as the complexity of the debugee (software + hardware).· Let's look beyond education to real-life usefulness.

Thanks for reading.
--Steve
·

jazzed · 2008-03-13 18:50

Lack of good debugging tools severly distracts from broader Propeller appeal. Ariba's PASD helps, but not for the easier and obscure SPIN language. Debugger for SPIN is more important because of the required learning curve.

Fabulous wealth is only provided to those who can serve a huge market. Of course big headaches will happen that will require the company to grow (Rocklin won't object). Something far better than the current model of "open sores support" would be required. Such are the choices we make. I expect Parallax has found their comfortable middle ground.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley

Traffic is slow at times, but Parallax orders·always get here fast 8)

Phil Pilgrim (PhiPi) · 2008-03-13 19:00

I know this is an unpopular position, but the only thing of any consequence I ever got from a hardware debugger was an unhealthy dependence on debuggers. A well-placed pin toggle, as Chip suggests, and a scope not only give you a real-time picture of your process, but force you to think about your program in ways that lead, ultimately, to a better, more incremental programming style and greater productivity. Also, it's easy to set up a separate cog to display the values of hub locations without disturbing running processes in other cogs. 'No special hardware required!

The problem with debuggers is that you get so distracted by breakpoints, single-stepping, watch variables, and the like that it's easy to become a slave to their magic and to lose sight of the larger picture. They really do turn into a crutch after a while. For a time, I too was mesmerized by the debug feature of the SX Key. But the more I programmed the SX, the more it just got in the way. Eventually I quit using the debugger altogether and haven't looked back.

By not including hardware debug in the Propeller, I think Chip is doing us all a favor.

-Phil

jazzed · 2008-03-13 19:28

Phil Pilgrim (PhiPi) said...
I know this is an unpopular position, but the only thing of any consequence I ever got from a hardware debugger was an unhealthy dependence on debuggers. A well-placed pin toggle, as Chip suggests, and a scope not only give you a real-time picture of your process, but force you to think about your program in ways that lead,

Perhaps you're right. I've been programming for 20 years and still find having a debugger helps me understand faults in my initial logic and helps me verify my code paths during unit testing. I just wish my O'scope was faster than 20MHz and those danged xor instructions were free [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley

Traffic is slow at times, but Parallax orders·always get here fast 8)

Martin Hebel · 2008-03-13 19:37

Debuggers were most useful to me when the cause of the bug was interrupts. Having registers and other conditions changing when I could see no problems, or to capture in real time why some code broke down due to an interrupt being triggers. The lack of interrupts in the Propeller takes away a big need on my end for seldom-used debuggers.

-Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
SelmaWare Solutions - StampPlot GUI for controllers, XBee and Propeller Application Boards

Southern Illinois University Carbondale, Electronic Systems Technologies

American Technical Educator's Assoc. Conference·- April, Biloxi, MS. -- PROPELLER WORKSHOP!

jazzed · 2008-03-13 21:42

Good debugging tools allow people to become acquainted with and emersed in a product for increased market share for OEM and advantages for the customer. The ROI for new grad who may need debugging and practical guidance than higher caliber guru is higher because of budget and more fluid attitudes.

One reason (out of 3 biggies) that large networking concerns with 20+ year old product implementation basis have so much India out sourcing is because new grads today are not designed to maintain old or non-mainstream Smile [noparse]:)[/noparse] because of lack of evolution (i don't blame anyone for this except managments too cheap to reinvest R&D dollars in a sustainable way as no one wants to maintain old Smile) There are literally millions of Indian engineers that you can hire and burn out on your old Smile and replace fairly easily. It's expensive and frustrating for many people in the industry to deal with such issues. Good judgment and understanding the legacy being built however helps to reduce problems and increase ROI.

The easier it is to use a design and maintain because of features implemented, the better; otherwise, you end up creating a place for yourself like a bad bathroom with a broken flusher, and when you're forced sell because you can't stand it anymore and you're lucky enough to have at least an attractive idea implemented, make sure you have a good lawyer to draw up your "closet skeleton warranty" so you don't end up on the other end of the big flush when it finally happens.

Serious products like Cavium's 16 core 800+ MHz Octeon Mips64 processor have ALL features that allows securing market share (that's THE reason Cavium is public and it's founders and principal employees are wealthy). However, it is unfair to compare Prop to Octeon because of function and target market which generally requires MSCS engineers. Seems those without such credentials, training, and proven experience would be better served better with ease of use more than OEM idealogical penny pinching.

Hardware emulators are useful for bringup. Interrupts could also be useful on propeller for asynchronous events, but not having interrupts is not a big loss unless you want use one to bring the device out of low power mode like the SX.

Prop has nice features, and the "promise" of more memory and cogs make staying with it attractive, but there are glaring ommissions such as little debug support and lack of register indirect data read/write asm instructions.

For the price and reasonable performance I'm still a fan. Whatever bigger Propeller Parallax can produce in a reasonable market window (which may close at any time) I will happily explore and may use on smaller projects where there is cost advantage and little maintenance requirement.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley

Traffic is slow at times, but Parallax orders·always get here fast 8)

Timothy D. Swieter · 2008-03-14 03:40

I'm with Phil about the debugger. I have used them in the past, they can help, but they also can hinder. I like thinking through a problem because it really helps me to learn and understand. Often times when I am debugging one problem I discover a better way to write the code or to accomplish the task. For me, a healthy part of the design is troubleshooting the problems in my software using pin toggling, an O-scope, a DMM and a serial link to HyperTerminal or an LCD display and finding those efficiencies or learning what doesn't work.

The Propeller is an awesome MCU. Learning it and using it has been easy (for me). A debugger can help with learning, but so can a blinking LED and a serial link with messages. I recommend slowly building your code, piece by piece and testing as you go along. The Propeller architecture lends itself to building code piece by piece because the code is easily broken across cogs/objects. This process of building piece by piece is not always easy in other MCUs (I am sure that could be debated though).

Perhaps what we the community needs to create is a document (or add to the Propeller wiki) techniques for troubleshooting and debugging with the propeller. The document starts off with general tips on writing clean code, building piece by piece, narrowing down and isolating problems, etc. Then, the document expands on ways to test such as how to insert a minimal amount of code to check for a status of a variable or a pin. Perhaps the document moves on further to discuss debugging serial connections with an O-scope or with a PC. Then at the end the document helps to develop an object that runs in its own cog that communicates with a PC and dumps data to it. The other program/cogs then give data, variables, pins that it should be watching. (Doesn’t something like this Propeller monitoring exist already?)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter

www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com

One little spark of imagination is all it takes for an idea to explode

stevenmess2004 · 2008-03-14 05:43

Timothy, there is already a page on debugging on the propeller wiki

There is also PASM for debugging assembly programs but I haven't tried it yet.

Paul Baker · 2008-03-14 18:10

I'm with Tim, Phil, Martin and Chip. Debuggers have become a drug to the masses, they are lured in by the apparent usefulness, but it comes at the price·of dependency. I also believe that debuggers lead to poorly thought out code which is only marginally working, I mean if the debugger says things are operating as I expect then the code is done, right? No, massaging the code through a debugger until it starts to work almost never results in the "best" code. Also debuggers lull the majority of coders into really bad programming practices, where they just code up everything (or close to it) and use the debugger to sort things out. Anyone who has taken a course in software development, or the product lifecycle, or worked in the real world in multi-team projects knows that this is the wrong way to write code. Programmers survived for decades without debuggers, but now we're incapable of programming without them? I just don't buy it (I believe the argument as much as·someone trying to convince me that you can't teach mathmatics without a calculator, or baseball can't be played without steroids, they are only tools and are certainly not the only means to an end).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 3/14/2008 6:25:41 PM GMT

Bean · 2008-03-14 18:32

Paul Baker (Parallax) said...
I just don't buy it (I believe the argument as much as·someone trying to convince me that you can't teach mathmatics without a calculator, or baseball can't be played without steroids, they are only tools and are certainly not the only means to an end).

Paul,
· I agree 100%. What did people do before calculators ?

· I guess there was no such thing as math before calculators. Or maybe there was but nothing really important could have been done without them.

· I find it funny that mathematicians used to be called "computers" because they computed tables and stuff.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com

·

jazzed · 2008-03-14 18:41

It's easy to take the Parallax position considering Chip's stand and opinions peers (of which I still respect).
It was also easy to buy a house near Rocklin for ~$600K in the last few years. Hope none of you got hurt.
Lemmings are a curious bunch.

I've made my case as a 20 year industry veteran; you can hide your pain when it comes. I'll say no more.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley

Traffic is slow at times, but Parallax orders·always get here fast 8)

Paul Baker · 2008-03-14 19:41

Why do you think we are lemmings because we agree with Chip? I would venture that people who clammor for this thing or that because "thats the way I've always done it" or "thats the way everyone else does it" would be more qualified to be labeled a lemming, but I personnaly wouldn't choose to hang the moniker on anyone.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 3/14/2008 8:02:31 PM GMT

hippy · 2008-03-14 19:41

I think there's one thing being missed in the discussion - accepting all the negatives debuggers can bring - and that's the usefulness they do provide when things do go wrong despite all the best intentions and best design efforts and testing.

Sure, I learned math long-hand, then with a slide-rule and now with a calculator. I don't use the calculator because I'm incapable of doing it otherwise, it's not a crutch for my inabilities, it's the easiest and best tool to use for the job.

To discount something because it may have a bad aspect to it is to ignore what good it has. Debuggers can be a means to an end which is far less painful than the alternative and that's their merit. If someone wants to debug their code with a flashing LED that's fine by me, but I'd prefer to have something which helps me find the bug without all the pain it otherwise involves.

Paul Baker · 2008-03-14 19:49

This isn't just a discussion on the pros and cons of debugging in general, but specifically debugging on the Propeller. And despite what people believe, it is by no means a simple task. I am fairly certain that a comprehensive debugger for a multiprocessing system where the entire system can be debugged simultanously has never been done in the entire history of computing. What exactly are you going to do with 8K longs·worth of variables staring you in the face for every step (and thats not counting hub memory), and more simplistically how would you display it all (have tabs and scroll bars, so everytime you want to look someplace different you have to go on a hunting expedition)? Also it requires alot of constructs that don't exist in the existing hardware, which means design, layout, fabricate, test, repeat for as many times as it takes to get the structure working correctly. This means extra time and money, there are also trickle down effects such as having to adjust the geometry of the cog, moving things around to make room for the extra hardware, so on and so on.

I've noticed that everyone seems to have ignored Chip's suggestion, why is a debugger any more powerful than his suggestion?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 3/14/2008 7:59:57 PM GMT

Rayman · 2008-03-14 20:01

I think it would be really neat if someone would implement the idea mentioned by Chip. Personally, a monitor is all I need to debug SPIN apps. But debugging assembly is a challenge... It seems like "Gear" (although I don't know too much about it) could be modified to do this...

jazzed · 2008-03-14 20:03

Ok. Sorry for lowering my self to one of many propagandist methods that are so pervasive in our culture these days.

I should state instead that "Humans are a curious bunch." [noparse]:)[/noparse]
Cheers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley

Traffic is slow at times, but Parallax orders·always get here fast 8)

Graham Stabler · 2008-03-14 20:09

logic is the best debugger, so there!

[noparse]:)[/noparse]

hippy · 2008-03-14 20:42

@ Paul Baker : I don't doubt it's not a simple task or that trying to debug a multiprocessing system with multiple Cogs and huge memory isn't difficult ( as it is for every developer now who has nothing and has to build up the debugging mechanisms from scratch ), but there does seem to me to be an element of "real programmers don't need debuggers" which crept into this thread.

I'd be quite happy with what Chip suggests; seems to be pretty much like an ICE to me, providing it can run full-speed and is non-intrusive, ie that the debugging mechanism doesn't interfere with the program being debugged itself and works.

Unfortunately we don't have that, it'd be great if we did.

The other alternative of flashing LED's, writing registers to memory locations works to an extent (I use those methods ), but it doesn't work well in all cases. Endlessly editing code, moving the hub writes around, downloading, checking what works and doesn't soon gets frustrating, when one finds where it's going wrong one still has to then find why it went wrong.

Debugging the Spin interpreter I wrote took hours to resolve some esoteric bugs with stack manipulation which would have been simple with a mechanism to step through the code and see what was happening. I've tried to use PASD and GEAR but it just didn't work for me.

I don't know exactly what debugging mechanisms are needed for the Propeller, but there has to be something better than what we have now.

Remy Blank · 2008-03-15 08:14

It's funny how such discussions always stay on the technical level.

I understand Chip and Paul's comments as follows: Parallax had to decide whether they should add debugging circuitry to the Prop or not. Besides technical feasibility, which seemed quite uncertain, there is also a commercial aspect. Adding debugging features must allow them to sell that many more Props so that the additional cost of developing them is covered. They seem to have come to the conclusion that the cost of implementing the debugging features is very high, and that the return would be low. Additionally, some already very useful debugging features can be implemented in software, at no additional cost.

IMHO, the decision is quite a simple one.

-- Remy

Graham Stabler · 2008-03-15 09:09

Now more seriously, if a problem can be solved with a step through then for me it seems easy enough to move a little hub write around or even flash and led if it is a case of finding out how far the program actually gets. I often also write cut down versions of my programs specifically to test certain aspects that "should work".

The propeller has the advantage of serial programming which means you always have a line of communication out of the chip which is very handy too, the fact that every chip has 8 processors is also a massive advantage, you can have fast core code running along side slow display code.

When it comes to anything real time where the prop interacts with other circuits or the physical world then stepping through has much less merit and you are back to flashing leds or sending pulses to a scope. So for me I would rather keep the chip real estate for RAM etc.

I don't think that Paul or Phil or even Chip are trying to put down debuggers or their users but rather say that they are not "all that". Sure if they exist a use can be found for them but there are advantages in not using them EVEN if it takes a little longer to find the bug. Sometimes working out a way in which to trap and reveal the bug is actually how you discover the bug in my experience.

hippy, what was it about PASD and GEAR that didn't work for you? I've not used them myself.

Cheers,

Graham

hippy · 2008-03-15 15:50

The fundamental problems with PASD were its need for 12 longs at ORG 0 when my design was using ORG 0 upwards to optimise code speed and spare code space was tight anyway, when scanning the source code it was not capable of correctly parsing and understanding the actual source I had. I cannot recall the exact details but I think it was because the source had things like this in it ...

x
        org      y
z       blah
        blah
        org      x

It isn't setup for LMM where code may be in Hub and it also didn't support "long value[noparse][[/noparse] count ]" which I was using within the Cog. The way it does break-point setting and the way I was doing LMM / self-modifying code was also in conflict somehow so during single stepping the debugger would simply 'disappear'.

I suspect, but never investigated, that there are problems executing 'jmp reg', and should 'reg' happen to point to somewhere it shouldn't, everything rapidly goes tits-up, PASD losing synch with what the Cog is actually doing. Similar with other self-modifying code.

Having forked my code off to a version which could potentially work with PASD ( hoping those changes did not obscure the bugs I was trying to track down ) it simply didn't work.

For GEAR I have even less recollection of what didn't work there.

This isn't to simply criticise either PASD or GEAR because I had a quite complex piece of code in the way it worked, and I cannot say how well they work with simpler code because I am also someone who doesn't believe in relying on debuggers and only use them when I need to.

The 'flaw' with PASD is that it is by necessity intrusive, needing to write breakpoints over code and unable to break on code which is self-modified. The idea is sound, it's standard background debugging fare, but what's really needed IMO is the hardware support which can make PASD work regardless of what the user's code is.

I've used the 'write breakpoints over code' method of debugging myself on other processors and this can work fine when there is no self-modifying code, but unfortunately the Propeller has self-modifying code as its backbone and self-modifying code cannot always be avoided. This can make such a debugging technique less useful and sometimes not useful at all. I'm really just asking Parallax to please provide some help to get round the problems their architecture poses.

hippy · 2008-03-15 16:37

I have a potential solution to the 'write breakpoint' problem which should improve what we have.

The biggest problem is that a breakpoint on any self-modifying code has to currently be in the form 'call #label', thus a MOV, MOVI, MOVD, MOVS, CALL or JMPRET can corrupt that breakpoint. If only the opcode bits were used to indicate a breakpoint only MOVI and a MOV to set an entire instruction would remain problematic, those are likely only used in a minority of code, and single stepping should be able to see the overwrite coming and fix the situation up afterwards.

What this would then require is a specific opcode to be allocated as 'breakpoint'.

The most obvious interpretation of 'breakpoint' to me would be 'jmpret $000,#$000' which should be easy to implement in silicon. Using 'jmpret $1EF,#$1F0' would be preferable to me, after a 'jmp #breakpointhandler' has been written to $1F0.

Everything else necessary for actual debugging would be in software as with PASD.

Open Letter to Chip Gracey

Comments