Remove "regression tests" section from website
Hey Felix, That's cool - like I say, just a drive by comment with an opinion - I am unfamiliar with the conversations that have happened on this over the years (I tried to read the more recent stuff but you have to knit it all together from either discussion board, ticket list or mailing list so it's easy to miss things.) But I don't see the benefit over just converting what we want (the "code" section), i.e. what we currently have at codeberg. I don't like the mono-repo layout, as it is backwards...
Hello, I've been reading the discussions in here and the mailing list after seeing Felix's update to the wiki and have some experience with this I think might be helpful. I'm an outsider looking in but I don't think continuing to do everything in Sourceforge is beneficial to the sdcc project or sustainable long term. See attached picture. On branches and working on multiple features at a time - I have more old-school colleagues from the SVN era who simply clone the repo more than once and check out...
1) adding chip_begin=banks[b]->chip_begin; to the end of cl_banker::activate, which makes ad->as_to_chip(space_addr) work correctly actually the start: if (banks[b] == NULL) return true; chip_begin=banks[b]->chip_begin; if (b == bank) return true;
read_cdb_file always assigns var to "rom" without considering banking
Hey, So, this in main.c? #pragma codeseg CSEG // ... unsigned char __sdcc_external_startup(void) { DPL1 = 0xFF; DPH1 = 0xFF; return 0; } Sorry if that seems like an obtuse question. I can always check the generated code : ) Out of curiosity which MCU are you using? I'll avoid naming the actual chip, it's produced by a popular Taiwanese IC design company and is an LCD controller (HDMI/VGA/Composite comes in, LVDS goes out). If I drop the part number you'll probably end up getting weird e-mails about...
Hi Maarten, Sorry, I didn't get the e-mail notifying me you'd replied - thanks for your help! Look at the generated code for returning from these functions. Sorry, yes, that seems very obvious in retrospect, of course since the banked return is always present then you always have to go through the banked call. Replicating the non-banked parts in the final binary can be handled by post-processing Thanks - this was a good pointer, for anyone else who ends up here via google the incantation I've ended...
Hi Maarten, Sorry, I didn't get the e-mail notifying me you'd replied - thanks for your help! Look at the generated code for returning from these functions. Sorry, yes, that seems very obvious in retrospect, of course since the banked return is always present then you always have to go through the banked call. Replicating the non-banked parts in the final binary can be handled by post-processing Thanks - this was a good pointer, for anyone else who ends up here via google the incantation I've ended...