> > > Walter Banks wrote: > >> Jim, >> >> TR 18037 allows direct access to the processors registers. If the >> condition codes are declared as a >> >> register volatile struct { >> int is_IRQ : 1; >> int disable_FIRQ : 1; >> int half_carry : 1; >> int disable_IRQ : 1; >> int N : 1; >> int Z : 1; >> int V : 1; >> int C : 1; >> } CC; >> >> then >> >> c = a + CC.C + b; >> >> should now generate a >> >> load a >> adc b >> store c >> >> sequence. Similarily other instructions that >> involve condition code access can now be used. >> >> w.. >> >>Jim Granville wrote:> Thanks, > Sounds like a worthwhile improvement (when supported:) , but it still > does not allow access to RR/RRC opcodes ? > > -jgWould this work if compiler is smart enough? #define RRC(c) CC.C?(c >> 1)|0x80:(c >> 1) #define RR(c) { unsigned short tmp; tmp = c & 0x80; c = (c >> 1) | tmp; } #define RLC CC.C?(c << 1)|0x01:(c << 1) #define RL(c) c = (c << 1) ; c |= CC.C; I/O accesses seems to be converted to ints before use, this sucks... iowr(PORT,iord(PORT) | (1 << bit)); to set a bit :-( PORT.bit = 1; Would be nicer... -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
What is the most "C unfriendly" architecture for which a workable C compiler exists ?
Started by ●June 3, 2006
Reply by ●June 8, 20062006-06-08
Reply by ●June 8, 20062006-06-08
Jim Granville wrote:> Thanks, > Sounds like a worthwhile improvement (when supported:) , but it still > does not allow access to RR/RRC opcodes ? > > -jgEven rather stupid compilers like sdcc will create rotate instructions for code like this: c = (c << 1) | (c >> 7); c = (c << 7) | (c >> 1); Philipp
Reply by ●June 8, 20062006-06-08
Ulf Samuelsson wrote:>> >>Walter Banks wrote: >> >> >>>Jim, >>> >>>TR 18037 allows direct access to the processors registers. If the >>>condition codes are declared as a >>> >>>register volatile struct { >>> int is_IRQ : 1; >>> int disable_FIRQ : 1; >>> int half_carry : 1; >>> int disable_IRQ : 1; >>> int N : 1; >>> int Z : 1; >>> int V : 1; >>> int C : 1; >>> } CC; >>> >>>then >>> >>>c = a + CC.C + b; >>> >>>should now generate a >>> >>>load a >>>adc b >>>store c >>> >>>sequence. Similarily other instructions that >>>involve condition code access can now be used. >>> >>>w.. >>> >>> > > Jim Granville wrote: > >>Thanks, >> Sounds like a worthwhile improvement (when supported:) , but it still >>does not allow access to RR/RRC opcodes ? >> >>-jg > > > Would this work if compiler is smart enough? > > #define RRC(c) CC.C?(c >> 1)|0x80:(c >> 1) > #define RR(c) { unsigned short tmp; > tmp = c & 0x80; > c = (c >> 1) | tmp; > } > #define RLC CC.C?(c << 1)|0x01:(c << 1) > #define RL(c) c = (c << 1) ; c |= CC.C; > > > I/O accesses seems to be converted to ints before use, this sucks... > > iowr(PORT,iord(PORT) | (1 << bit)); > > to set a bit :-( > > PORT.bit = 1; > > Would be nicer...Certainly would, it would bring C code to where Modula-2 has been for over 15 years :) I think Walter's example should also expand for Ports, as he creates a struct of bits ( tho each element is int :1, not bit, which I thought was now C-legal ? ) ie if one can accsss Carry as CC.C, then any port should be accessible as PortName.BitName ? -jg
Reply by ●June 8, 20062006-06-08
please change the subject line when you change the subject CBFalconer wrote:> Walter Banks wrote: > > > > Part 1.1 Type: Plain Text (text/plain) > > Encoding: 7bit > > Please don't use html and/or attachments in usenet. > > -- > "Our enemies are innovative and resourceful, and so are we. > They never stop thinking about new ways to harm our country > and our people, and neither do we." -- G. W. Bush. > "The people can always be brought to the bidding of the > leaders. All you have to do is tell them they are being > attacked and denounce the pacifists for lack of patriotism > and exposing the country to danger. It works the same way > in any country." --Hermann Goering.
Reply by ●June 8, 20062006-06-08
Our C compilers can access PortName.BitName. In the more general case ports can more than one bit field be typed or mapped on structs. There was a lot of effort in when TR18037 was written to include those things that collectively we has some experience with. Access to the registers and user defined memory have seen a lot of use. w.. Jim Granville wrote:> Ulf Samuelsson wrote: > > >> > >>Walter Banks wrote: > >> > > Certainly would, it would bring C code to where Modula-2 has been for > over 15 years :) > > I think Walter's example should also expand for Ports, as he creates a > struct of bits > ( tho each element is int :1, not bit, which I thought was now C-legal ? ) > > ie if one can accsss Carry as CC.C, then any port should be accessible > as PortName.BitName ? > > -jg
Reply by ●June 8, 20062006-06-08
Walter Banks wrote:> Our C compilers can access PortName.BitName. In the more general case > ports can more than one bit field be typed or mapped on structs. >Many do, but is it "Embedded C"?> There was a lot of effort in when TR18037 was written to include those > things that collectively we has some experience with. > > Access to the registers and user defined memory have seen a lot of > use. >But can you define which register you are using? The IAR construct: __no_init __regvar unsigned char my_register_variable @ 2; tells you to use register 2. This is very useful for small applications, allowing global variables in regusters. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Reply by ●June 9, 20062006-06-09
We have implemented the parts of Embedded C that are applicable to each of the compilers we have implemented in the last few years. All of them have fixed point arithmetic (fracts and accums) and all of them have named address spaces and named register storage classes. Ulf Samuelsson wrote:> Walter Banks wrote: > > Our C compilers can access PortName.BitName. In the more general case > > ports can more than one bit field be typed or mapped on structs. > > > > Many do, but is it "Embedded C"?The Embedded TR18037 formally defined this wide spread practice.> But can you define which register you are using?Global variables can be allocated to specific registers or allocated to the next available register. The compiler sees this as an application constraint and creates code using the remaining registers for locals and temporaries.> This is very useful for small applications, allowing global variables in > regusters.Agreed. w..
Reply by ●June 10, 20062006-06-10
Le Sat, 03 Jun 2006 10:05:04 +0200, Anton Erasmus a écrit :> Hi, > > Since there is a thread on "C friendly" architectures, I thought it > might be interested to find out what sort of horrible architectures > compiler writers actually managed to create a C compiler for. > (And what portion of the ISO C standard is/was not supported) > I asked the question (emailed Plauger if I recall correctl) once, on > why there is no "rotate" operator in C. ALL the architectures I have > ever work on had a direct assembly instruction for rotating a > register. The answer was that there were architectures which C > supports on which a "rotate" instruction made no sense. An example > was mention of an architecture that had NO integer support at the > assembly level. Integer operations had to be emulated using floating > point instructions. > > Regards > Anton ErasmusPIC and 6805, 6808 C Code generated for 68xx and 8051 is usually bloated. If you design with a PIC you will prefer a C Compiler, CCS does a good one that masks all the weird stuff and you don't have to worry about the ridiculous paging system. -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal We are the Cybernetic Entomology Experts
Reply by ●June 10, 20062006-06-10
Alex Colvin wrote:> >Since there is a thread on "C friendly" architectures, I thought it > >might be interested to find out what sort of horrible architectures > >compiler writers actually managed to create a C compiler for. > > There was an early C compiler for the GE 635, which had (36-bit) word > addressing. Characters (6-bit) and bytes (9-bit) could be addressed only > via extra indirection words. Where an ordinary pointer fit in 18 bits and > could be in a register, byte or character pointers needed 36 and could > only be in memory.I thought someone else would mention it by now, but another notorious example is the word-addressed DG Nova, which required a separate pointer format to address bytes. C compilers existed for this architecture; Chris Torek and Michael Meissner often mention its quirks: http://groups.google.com/group/alt.folklore.computers/msg/b7a12c8764051e8e http://groups.google.com/groups?as_q=3Dnova+pointer&as_uauthors=3Dchris+tor= ek> > On the other hand, it was otherwise pretty conventional - flat address > space (unless you were running Multics on a VM-enabled processor), > call/return through registers or memory stacks, twos complement. >=20 >=20 > --=20 > mac the na=EFf
Reply by ●June 10, 20062006-06-10
On 10 Jun 2006 14:25:39 -0700, "toby" <toby@telegraphics.com.au> wrote:>Alex Colvin wrote: >> >Since there is a thread on "C friendly" architectures, I thought it >> >might be interested to find out what sort of horrible architectures >> >compiler writers actually managed to create a C compiler for. >> >> There was an early C compiler for the GE 635, which had (36-bit) word >> addressing. Characters (6-bit) and bytes (9-bit) could be addressed only >> via extra indirection words. Where an ordinary pointer fit in 18 bits and >> could be in a register, byte or character pointers needed 36 and could >> only be in memory.The same problems occurred with the Univac-11xx series, which used word addressing with 36 bit words and 6/9 bit characters.>I thought someone else would mention it by now, but another notorious >example is the word-addressed DG Nova, which required a separate >pointer format to address bytes.This problem also occurs with any 16/24/32 bit DSP, which do not have byte addressing. In many Pascal systems, this problem was solved with the "packed array of char", which had a limited set of operands compared to "array of char", in which each character occupied a memory word. In future high level systems with 64 bit ALUs, do we really need 8 bit byte addressing ? The 8 bit byte is insufficient to express all characters in many major languages of the world. The Unicode scalar value (USV) range is 0.. 0x10FFFF, thus requiring 21 bits, thus, three Unicode characters would nicely fit into a 64 bit word with one spare bit ("UTF-64"). Some kind of packed array of char mechanism would be required to access individual characters. Paul
