From: <kus...@sp...> - 2022-12-25 18:04:04
|
A trivial self contained test case did not fail. So I started to think about what is unique in my project. The answer is 'a lot of ORG' statements. I started to bisect and strip down my code and after some elbow grease my guess is that around 128 non discontinuous sections we get this error. I will try to create simple test case to prove this and also to find out if this is per file limitation or per executable limitation. wbr Kusti > On 25. Dec 2022, at 14.48, kus...@sp... wrote: > > > >> On 25. Dec 2022, at 14.28, Rob Pearce <lis...@fl... <mailto:lis...@fl...>> wrote: >> >> On 25/12/2022 13:00, kus...@sp... <mailto:kus...@sp...> wrote: >>> Hi Roy, >>> >>> thanks. Where did you get your source? I got mine like this: >>> >>> svn checkout svn://svn.code.sf.net/p/gpsim/code/trunk <svn://svn.code.sf.net/p/gpsim/code/trunk> >>> >>> >>> I just managed to compile it on macOS: >>> >>> gpsim-0.31.1 #2607 (Dec 25 2022) >>> >>> and I see the issue there. >>> >>> After hacking p18x.h:671 to >>> >>> unsigned int program_memory_size() const override { return 0x8000; } >>> >>> My error now is >>> >>> increment PC=0x8000 == memory size 0x8000 >>> >> Looking through the ChangeLog, I see this entry: >> >> 2008-08-26 Rob Pearce <ro...@bd...> <mailto:ro...@bd...> >> * src/processor.cc <http://processor.cc/> src/processor.h src/sim_context.cc <http://sim_context.cc/> src/cod.cc <http://cod.cc/> >> src/16bit-processors.h gui/gui_profile.cc <http://gui_profile.cc/> : >> Corrections to use of Processor::program_memory_size() so that all >> of them expect it to be instruction words, not byte addresses. >> That being the case, the correct return value should be 0x4000 (it's written as 16384 in the svn HEAD) but that should map to 0x8000 as a PC value. However, given that the interpretation had to be "corrected" back in 2008 it wouldn't surprise me if there are places where it's misinterpreted still (or again). >> >> Regards, >> >> Rob >> >> _______________________________________________ >> gpsim-devel mailing list >> gps...@li... <mailto:gps...@li...> >> https://lists.sourceforge.net/lists/listinfo/gpsim-devel > > Thank, I see. > > So my test hack was just wrong. > > But I'm now thinking if there is (also) a problem witht .cod file generated by gpasm. > Reading through cod.cc <http://cod.cc/> I I find: > > * Memory map table - describes the ranges of memory used in the processor. > > If this refers to the actuall processor type and not just what is compiled for that particular piece of code then if might be that the processor spec for gpasm is faulty in someway. > > This rabbit hole gets deeper all the time. > > wbr Kusti > > > > _______________________________________________ > gpsim-devel mailing list > gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsim-devel |