| bitrex <bitrex@de.lete.earthlink.net>: Dec 30 08:10AM -0500 On 12/29/2017 03:46 PM, Vir Campestris wrote: > It must be a very small and specialised chip that doesn't have a HW > multiplier. Heck, even an 8080 had one of those... What is it? > Andy <https://www.microchip.com/wwwproducts/en/ATtiny85> Nah, I'm still in my 30s. :-) The Microchip (formerly Atmel) RISC 8 bits ain't my grandad's 8 bit! 32 registers, most instructions execute in one clock cycle. At 20 MHz I can run multiple fixed-point digital filters on there fed from the 10 bit ADC channels, no problem at all. An 8x8 unsigned software-multiply IIRC comes in at under 40 clocks. You can cram a lot of C++11 in 8k program memory and 512 bytes SRAM. The current project I'm working on is nearly 2000 SLOC in C++ and with link-time optimization comes in occupying about 6k of the program space. |
| Dombo <dombo@disposable.invalid>: Dec 30 03:28PM +0100 Op 29-Dec-17 om 23:16 schreef Robert Wessel: > the Z-80, or their contemporaries, the 6800 and 6502. For examples of > more current architectures without a multiplier, there are the low end > PICs and the smaller AVRs. Only the smallest (i.e. ATtiny) 8-bit AVRs. Most 8-bit AVRs do have a 2-cycle hardware multiplier. These days you have to use a very low-end CPU not to get a hardware multiplier, I doubt there exists a reasonable C++ compiler for those. |
| David Brown <david.brown@hesbynett.no>: Dec 30 08:33PM +0100 On 30/12/17 15:28, Dombo wrote: > 2-cycle hardware multiplier. These days you have to use a very low-end > CPU not to get a hardware multiplier, I doubt there exists a reasonable > C++ compiler for those. There used to be some quite large AVR's without multipliers. Some designs are long-lived, and still work with such old devices (AVRs or other microcontrollers). There are still a depressing number of 8051-based devices around (small USB devices, Z-Wave chips, "smart" ADCs, etc.). And in some cases, you can use C++ just fine. C++ (excluding exceptions and RTTI, which is usually what you want anyway) works just fine across the board for AVRs - even the smallest devices. But for modern chips there is are very few that don't have hardware multiply, even at the low end. |
| Dombo <dombo@disposable.invalid>: Dec 30 11:05PM +0100 Op 30-Dec-17 om 20:33 schreef David Brown: > other microcontrollers). There are still a depressing number of > 8051-based devices around (small USB devices, Z-Wave chips, "smart" > ADCs, etc.). The 8051 does have a multiply instruction. > And in some cases, you can use C++ just fine. C++ (excluding exceptions > and RTTI, which is usually what you want anyway) works just fine across > the board for AVRs - even the smallest devices. I didn't intend to imply that you can't have a C++ compiler for a low-end CPU core, just that it less likely someone has bothered to make one. The really low-end CPU cores (below lets say the 8-bit AVRs) tend to be more awkward in several aspects (Harvard architecture, bank-switching, very limited stack...etc.) making it harder to make a halfway decent compiler for them and due to their limited nature also less necessary. My experience with the 8-bit AVRs is that one do need to adapt ones C++ coding style significantly to suit the limitations of this microcontroller to get the compiler to produce something that is memory- and performance-wise reasonably efficient. This makes it unlikely that one could just use a generic C++ library that is not written with the limitations of 8-bit AVR in mind and expect a acceptable result. Once you get to the slightly higher end processors (e.g. ARM Cortex M0) this becomes less and less of an issue. > But for modern chips there is are very few that don't have hardware > multiply, even at the low end. These days one can expect a hardware multiplier in contemporary microcontrollers that cost 1 USD or even less in small quantities. Unless one intends to target extremely price-sensitive and very high volume markets, it does make little sense to me to worry about CPUs without hardware multiplier. |
| bitrex <bitrex@de.lete.earthlink.net>: Dec 30 05:44PM -0500 On 12/30/2017 05:05 PM, Dombo wrote: > bank-switching, very limited stack...etc.) making it harder to make a > halfway decent compiler for them and due to their limited nature also > less necessary. There's not much below the ATTiny series; an ATTiny85 is around 75 cents in quantity. You get 8k of program space and 512 bytes of SRAM for your money, and C++11 code using all the "modern" features except for dynamic allocation and smart pointers works well via avr-gcc. Templates, policy-based design, abstract virtual classes, lambdas, all the stuff. |
| David Brown <david.brown@hesbynett.no>: Dec 31 12:23AM +0100 On 30/12/17 23:05, Dombo wrote: >> 8051-based devices around (small USB devices, Z-Wave chips, "smart" >> ADCs, etc.). > The 8051 does have a multiply instruction. There are many 8051 variants - I think only some have multiply hardware. (Even if they have multiply hardware, 8051 cores are still depressing!). > I didn't intend to imply that you can't have a C++ compiler for a > low-end CPU core, just that it less likely someone has bothered to make > one. I don't expect anyone intentionally planned to make a C++ compiler for an AVR tiny! But the AVR family are all supported by gcc - once you have the C compiler working for them, the basic C++ support is free. Last I heard, there was minimal C++ library support for avr-gcc, and thus things like exceptions don't work. (Header libraries are fine, of course.) IAR certainly has C++ support for some small microcontrollers. I haven't looked at the details there, and don't know which ones they support. > bank-switching, very limited stack...etc.) making it harder to make a > halfway decent compiler for them and due to their limited nature also > less necessary. That is certainly true. But support for C++ (at least baring exceptions) is not much harder than supporting C. Once you have a C compiler, most of the work of C++ support is in the front end - and that will be common for a whole family of different targets. Of course, that does not mean you get /efficient/ C++ support. Virtual methods are going to be really big and slow on a COP8, 8051 or PIC16. It's just that /if/ you have made a C compiler for them, and you already have a C++ front end for your ARM targets (or whatever), then supporting virtual methods (or any other C++ feature) is not actually that much work. > coding style significantly to suit the limitations of this > microcontroller to get the compiler to produce something that is memory- > and performance-wise reasonably efficient. Yes, you usually want to write code in a specific way for that kind of chip. It applies to C as well. You make a lot more use of uint8_t and int8_t than you normally would, for example (since these are 8-bit cores). You minimise the use of pointers, as their pointer registers are not great. You need compiler extensions to make efficient use of read-only data in flash rather than ram. > limitations of 8-bit AVR in mind and expect a acceptable result. Once > you get to the slightly higher end processors (e.g. ARM Cortex M0) this > becomes less and less of an issue. Agreed. > Unless one intends to target extremely price-sensitive and very high > volume markets, it does make little sense to me to worry about CPUs > without hardware multiplier. We are getting to that stage. There are still cases where a Cortex M0 is too big, too slow, too power-hungry, too expensive - but it is a rapidly shrinking section of the market. (I once knew someone whose job was cost reduction for board designs. With the boards he worked on, if he could find a way to eliminate a single SMD resistor, it would justify his year's salary.) Still, many designs don't change much and last a long time - it can be far more efficient to keep the same 15 year old device on the board than swap it for a new device and re-do much of the development. For new designs, however, it is going to be very rare that you don't have a 16-bit or 32-bit core with hardware multiply and tools with at least reasonable C++ support. |
| legalize+jeeves@mail.xmission.com (Richard): Dec 30 12:27AM [Please do not mail me a copy of your followup] Vir Campestris <vir.campestris@invalid.invalid> spake the secret code >But if you value your sanity do NOT attempt to study the actual code. >Every implementation I have seen has efficiency at execution time first, >speed of compilation second, and readability not even on the list. Yeah, it's pretty hard to read, particularly since all their internal identifiers are splat blasted with leading _'s because those are the portions of the identifier space reserved for the implementation. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment