Is the example code a port from a bigger system? K&R warns against using macros in loops. Experienced programmers (especially embedded) know not to write code like shown in the "reason" for needing this change.
At this point the acid test is sizeof(how many macros) == "256 | 512" (If we cannot use MPU) I still feel it should be a CONFIG setting and default it to the table, describe the pit falls in Knonfig if it is changed to a macros and document the code bloat in the README. This will save past users on Nuttx, on constrained system, to have a chance to fix running out of FLASH space when isalpha() is used one (properly). Maybe this is not as important to companies with their own chip foundries, but we still need to be inclusive. David -----Original Message----- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Tuesday, July 28, 2020 11:54 PM To: dev@nuttx.apache.org Subject: RE: Can we implement ctype functions through table? The new option just make the situation worse. The same code works in some configurations, but breaks in other configurations. Since the standard confirmation is the most important principle for NuttX, we have three options: 1.Implement ctype function with table and add 256 byte to ROM 2.Change macro to normal function and lose some performance 3.Change macro to inline function and some old compilers may generate the bloat code all ctype functions are one line code, so option 3 may be a good compromise. > -----Original Message----- > From: David Sidrane <david.sidr...@nscdg.com> > Sent: Tuesday, July 28, 2020 8:23 PM > To: dev@nuttx.apache.org > Subject: RE: Can we implement ctype functions through table? > > Xiang, > > If there is a small usage do you think flash will grow by 256 bytes? I > would be surprised. > > Should you uses a config option? > > David > > > -----Original Message----- > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] > Sent: Monday, July 27, 2020 10:40 PM > To: dev@nuttx.apache.org > Subject: RE: Can we implement ctype functions through table? > > Decorate the table with IPTR and access the element through up_romgetc, > just like printf series function. > > > -----Original Message----- > > From: Gregory Nutt <spudan...@gmail.com> > > Sent: Tuesday, July 28, 2020 12:44 PM > > To: dev@nuttx.apache.org > > Subject: Re: Can we implement ctype functions through table? > > > > What about platforms like AVR? That would not be a good decision for > > AVR since it is a harvard machine and cannot access data in ROM > > without special operations. > > > > > > On 7/27/2020 9:55 PM, Xiang Xiao wrote: > > > Hi all, > > > For example, here is isspace implementation: > > > # define isspace(c) \ > > > ((c) == ' ' || (c) == '\t' || (c) == '\n' || (c) == '\r' || \ > > > (c) == '\f' || (c) == '\v') > > > The argument of c will evaluate 6 times, which make the following > > > code suddenly fail: > > > while (end != begin) > > > { > > > If (!isspace(*--end)) > > > { > > > break; > > > } > > > } > > > But it work well with other libc implementation, because all other > > > libc utilize a table to classify the char type: > > > https://github.com/bminor/newlib/blob/master/newlib/libc/include/cty > > > pe > > > .h#L97 > > > https://github.com/bminor/glibc/blob/master/ctype/ctype.h#L197 > > > and the argument only need evaluate once. > > > So my question is: can we implement ctype functions through table to > > > improve the compatibility? > > > Yes, the table need take more 256 bytes ROM space, but the complex > > > expression used in NuttX also bloat the code size, especially > > > considering ctype function is used very frequently. > > > > > > Thanks > > > Xiang > > >
