On Sun, 13 Jan 2013 17:37:00 +0100 Raphael Neider <rnei...@web.de> wrote:
> Hi, > > > This would be good for a new type: __sfr16_t --- "t" -> timer > > > > Perhaps even these will: __sfr16_be --- "be" -> big-endian > > __sfr16_le --- "le" -> > > little-endian > > > > Otherwise, I now updated the PIC16 branch (device and include files). From > > now on use the __ sfr16 > > type. Due to the above to TMRx registers, no sfr16. > > What are the consequences to code generation functions if you > introduce a new type / new types in order to guarantee LSB first/MSB > first access? Only so register pairs were given the 16-bit access, where indifferent the order of access. The TMR registers are therefore I let out of this. The newer models were only ideas. Only I have created an opportunity for testing, if it already exists in the __sfr16 type. > Are sfr/__sfr16 data first read via some volatile read > fuction (iCode?), then processed, and then written back via some > volatile write function (iCode?)? Otherwise, probably all code > generation functions need to be revised to guarantee proper behaviour > [1]. > Do you plan to introduce all four probably variations of 16-bit SFRs > (read order LSB or MSB first vs. write order LSB or MSB first)? > > I am not even sure if all (PIC14/PIC16) functions properly honor > volatile -- they might read/assign their operands multiple times, > possibly even depending on runtime conditions. > > Are we sure not to introduce additional, subtle bugs here? > > Do not get me wrong: I'd like direct support for multi-bype SFRs, I > just want to avoid special cases throughout the backend. > > > __at(0x0FC3) __sfr ADRES; > > > > __at(0x0FC3) __sfr ADRESL; > > __at(0x0FC3) __sfr16 ADRESw; > > > > __at(0x0FC4) __sfr ADRESH; > > Do gputils (gplink) allow this? I performed a test. The compilation of all pic18xxx.c device files succeeded without error. > We end up with ADRESL and ADRESw > occupying 0xFC3 as well as ADRSH and ADRESw occupying 0xFC4. *Should* > the linker allow this?!? > But, unfortunately, I has just discovered that the gplink produce errors. :-(( > Best regards > Raphael > > > [1]: I assume that SFRs should be usable in statements such as > > ADRESw += 0x0101; > > even though as user one *should* probably use > > unsigned temp = ADRESw; > temp += 0x0101; > ADRESw = temp; > > which would then only require assignments from / to SFR types to be > handled correctly. I restore the previous state. I wanted to help, but I was careless. Excuse me. Károly ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
