From: <kus...@sp...> - 2022-12-26 09:04:01
|
> On 26. Dec 2022, at 8.21, Rob Pearce <lis...@fl...> wrote: > > On 26/12/2022 07:04, kus...@sp... wrote: >> the actual execution may work (and thus avoid the error message completely) >> once I get the code load properly to gpsim. > > Quite likely your code will work better if it's actually loaded... at all! The .cod error you're seeing at line 181 of cod.cc prevents any of the binary image being loaded, so your simulated flash is all blank. :) Hard for gpsim to work as if the code fails to load ;) should have paid more attention to that error message in the first place. Couple of hours of editing and some helpful macros cut down the +260 absolute sections to somewhere around 100 and now the code loads and runs, much as expected. > > I'm not sure whether the problem is an absolute limitation of the COD file format or a limit of GPSim's parser. It throws that error if two adjacent page references aren't the same, but I don't know the format well enough to say what that means. It's not inconceivable that the format actually defines those fields as a first-and-last pair for block allocations, and when you hit 128 separate blocks the linker needs to allocate more than one page to the alloc block. Yeah, COD is made of 512 byte blocks so yeah that would do it. > If that's the case, I think this is a bug in GPSim, just one that very few people ever trigger, and quite possibly one that was done deliberately because the author didn't expect anyone ever could trigger it. It would be pretty hard on a device with as little flash as the early PICs. Right. Call it not a bug but a limitation, and I've already worked around it. Took me three years ;) but no matter. This is a fun project anyway to keep me entertained on holidays. I originally used this computed GOTO approach and hit this speed bump (cod range error) three years ago, but back then I changed my approach to use an intermediary jump table which allowed me to get rid of all of those abs sections and replace them with 256 labels and GOTOs. Turns out I cannot afford those 2 clock cycles at that point in execution so I had to come back to this original approach. > > Cheers, > > Rob thanks and cheers Kusti |