- Vector Fractal Bloom... - 1 Update
- CHAR_BIT is not eight - 9 Updates
- What a reference actually is - 6 Updates
- What is a `**ppEnum`? - 1 Update
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 18 11:18AM -0800 On 5/12/2022 12:16 PM, Chris M. Thomasson wrote: > Using my experimental vector field to generate a fractal formation. Here > is generation two: > https://fractalforums.org/gallery/1612-120522191048.png Another biomorphic experiment of mine: https://youtu.be/IVR5I5mnrsg Just having some fun for now, in C++. |
| Richard Damon <Richard@Damon-Family.org>: Nov 17 11:23PM -0500 > To be fair a lot of microcontrollers have those too. I would define a DSP as > something that can do ADC and/or DAC itself, ie it can process external data > directly and the TI chips AFAIK can do that. Analog <-> Digital conversion is not what makes a DSP a DSP. MANY ordinary microcontrollers have analog devices built in. DSP chips tend to be one optimized to do Multiply and Accumulate operations, particularly between vectors of values. |
| David Brown <david.brown@hesbynett.no>: Nov 18 08:16AM +0100 On 18/11/2022 05:23, Richard Damon wrote: > ordinary microcontrollers have analog devices built in. > DSP chips tend to be one optimized to do Multiply and Accumulate > operations, particularly between vectors of values. Yes. "DSP" is an aspect of the core and surrounding parts (such as specialised memory blocks). It means /Digital/ Signal Processing - it is independent of whether the device has /analogue/ signal handling. (Most serious DSP's don't, as the kind of device and surrounding electronics and layout that you need for quality analogue is very different from what you need for the digital parts of your system.) |
| Michael S <already5chosen@yahoo.com>: Nov 18 03:47AM -0800 On Friday, November 18, 2022 at 6:24:03 AM UTC+2, Richard Damon wrote: > ordinary microcontrollers have analog devices built in. > DSP chips tend to be one optimized to do Multiply and Accumulate > operations, particularly between vectors of values. In practice, stand-alone DSP chips almost never had on-chip ADCs or DACs. Not because they didn't want, but because it precludes implementation on relatively modern silicon processes. And it is quite important for DSPs to be implemented on relatively modern process, because MOPs/Watt is far more important selling point for DSP than for MCU. All that applies to 1980 to ~2005. Later on stand-alone DSPs turned into shrinking and fragmenting niches. And after both leading manufacturers of stand-alone DSPs left the race for finer geometries, it became even harder to spot any trends. |
| scott@slp53.sl.home (Scott Lurndal): Nov 18 02:52PM >Later on stand-alone DSPs turned into shrinking and fragmenting niches.=20 >And after both leading manufacturers of stand-alone DSPs left >the race for finer geometries, it became even harder to spot any trends. Nowadays one just licenses the IP from Tensilica or Ceva and tape it out as part of a larger SoC package. |
| Muttley@dastardlyhq.com: Nov 18 04:32PM On Thu, 17 Nov 2022 23:23:46 -0500 >ordinary microcontrollers have analog devices built in. >DSP chips tend to be one optimized to do Multiply and Accumulate >operations, particularly between vectors of values. Using that definition x86 post pentium are DSPs. |
| Muttley@dastardlyhq.com: Nov 18 04:33PM On Fri, 18 Nov 2022 08:16:26 +0100 >Yes. "DSP" is an aspect of the core and surrounding parts (such as >specialised memory blocks). It means /Digital/ Signal Processing - it >is independent of whether the device has /analogue/ signal handling. You won't be processing any signals if you can't get the data which 99% of the time will be originating in the analogue realm. |
| David Brown <david.brown@hesbynett.no>: Nov 18 06:54PM +0100 >> is independent of whether the device has /analogue/ signal handling. > You won't be processing any signals if you can't get the data which 99% of > the time will be originating in the analogue realm. Lots of data originates as digital, at least as far as your processing is concerned. Any kind of media player (music, TV, etc.) uses digital signal processing to handle signals that are digitised long before your telephone, TV or DAB radio ever sees it. And even when the electronics board in question takes in an analogue signal for processing, it is very frequently /not/ in the DSP device - it is digitised in a separate analogue to digital converter. Similarly, output goes through a separate digital to analogue converter of some kind. Analogue inputs are /much/ more common on /microcontrollers/, than on chips that are classified as DSP's. The TMS320 series are unusual in that they combine features of both kinds of chip. |
| David Brown <david.brown@hesbynett.no>: Nov 18 07:05PM +0100 >> DSP chips tend to be one optimized to do Multiply and Accumulate >> operations, particularly between vectors of values. > Using that definition x86 post pentium are DSPs. Do you understand the difference between the phrases "are optimised for" and "are good at" ? The fact that general-purpose processors have been getting better at handling DSP algorithms does not make them DSPs. It /does/ mean the market for DSP's has dropped significantly - few people bother with the complexities of a DSP design if you can just use an ARM microcontroller or a desktop PC. But general purpose PC's do this by brute force, with a few DSP-style operations like MAC. High-class DSP cores will have instructions that combine fetch of data from 3 different sources at once, apply a MAC to them, saturate the results, store the results, increment all the pointers involved with circular buffer wrapping where needed, decrement and check a loop counter, and perform the loop - all in a /single/ instruction, in a /single/ clock cycle (with a few cycles pipelining). They will keep this up continuously - no cache delays, scheduling issues, history buffers, or any other unexpected variations in speed. Some will do several of these operations in parallel - in each core. That is their purpose, and they do it very well - orders of magnitude more efficiently than using a fast desktop PC. The reason you no longer see so many DSP's is that general purpose CPUs do the job fast enough, and you have the CPU anyway. Once you can decode audio or video fast enough to watch, there's no need to go faster. (Actually, the main reason you don't see DSP's is that they are hidden inside equipment and most people have no idea there's a processing element in there.) |
| scott@slp53.sl.home (Scott Lurndal): Nov 18 06:16PM >(Actually, the main reason you don't see DSP's is that they are hidden >inside equipment and most people have no idea there's a processing >element in there.) A good example is 5G base stations to process the 5G waveforms. |
| JiiPee <kerrttuPoistaTama11@gmail.com>: Nov 18 07:49AM +0200 On 18/11/2022 00:36, Paavo Helde wrote: > With C++, my advise is to not use raw pointers in your code except when > forced by interfaces that are out of your control. Prefer references > instead, I have done C++ since 1997 and I agree. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 18 09:40AM > For language that is so similar (nearly identical) to C at the level of > "virtual machine", as is C++, the concept of reference is just unnecessary. If we start dismissing everything that one could deem "unnecessary" then we could start dropping off quite many features even from C itself. After all, for example the syntax 'a[b]' is just syntactic sugar for '*(a+b)', and thus the former is "unnecessary" and could just be dropped off. A 'for()' statement is unnecessary because you can write the same thing using a 'while()' statement. And obviously the 'do' keyword is completely unnecessary. As well as the 'switch' keyword. And why do we even need a 'const' keyword at all? That could be easily dropped off. We could easily drop half of C syntax as "unnecessary" and still be able to write the same programs as before. Not to talk about C++! > Don't use references in your code except when forced by interfaces that > are out of your control! Then people that are going to read and comprehend > your code will be thankful. Actually references add useful abstraction to interfaces. For example, when you write 'foobar(abc)', is that 'foobar' function taking the parameter by value or by reference? It can decide! Whatever is best in that particular function, it can choose. The calling code doesn't need to tie its hands and force one or the other. Moreover, if later it turns out that the function would need to change how it takes the parameter (for example it originally took it by value, but the type got a lot larger after a refactor, so now it would be more efficient to take it by reference), it can do so without breaking any code that's calling the function. (And no, "just fix all the places where the function is called, by following the compiler errors" is not a good solution because this may be a library used somewhere, and you will be breaking the API, causing it to become incompatible with the previous version, forcing every project that uses the library to fix all the calls.) Also, how do you suggest implementing copy constructors and operator overloading without references? |
| Michael S <already5chosen@yahoo.com>: Nov 18 03:23AM -0800 On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote: > After all, for example the syntax 'a[b]' is just syntactic sugar for > '*(a+b)', and thus the former is "unnecessary" and could just be dropped > off. The [] variant is shorter by 2 characters. In DRM view, shortness of most frequently used language features was of high priority. Also, in slightly more complex expressions, in case of *(a+b) variant reader has to look for more information in order to figure out which of two homonyms of * is actually used. I would speculate that DRM was not really pleased with using asterisk for dereference, but had no better choice in available character set. A 'for()' statement is unnecessary because you can write the same > thing using a 'while()' statement. Except that 'continue' behave differently. The better argument is that 'while' loops are unnecessary and that is absolutely correct. A mistake on part of DRM. > And obviously the 'do' keyword is completely unnecessary. I don't see it. Please elaborate. > As well as the 'switch' keyword. What alternative do have in mind? if-else-if chains? Both more typing and intentions of using the same selection variable for all choices is not pronounced clearly. > And why do we > even need a 'const' keyword at all? That could be easily dropped off. People argue for that. IIRC, 'const' is relatively late addition to C, so likely DRM was not very sure about it. Personally, I find it useful, primarily for documenting of intent. The claim that it often helps to catch bugs is hard to prove. As to C++ [mis]use for peeking one of polymorphic methods... well, it's pretty bad, but not the worst thing caused by polymorphic methods. > We could easily drop half of C syntax as "unnecessary" and still be able > to write the same programs as before. Not to talk about C++! So, you don't think that C++ will become a better language if 2/3rd of it is dropped? I was under impression that just about everybody agree about that. Of course, they rarely agree about what third to retain. > will be breaking the API, causing it to become incompatible with the > previous version, forcing every project that uses the library to fix > all the calls.) If only const references were allowed as function arguments I'd wholeheartedly agree with majority of above paragraph. Unfortunately, mutable references are as legal as const ones and the reader of the code has no hint about which variant was used by looking at function call. > Also, how do you suggest implementing copy constructors and operator > overloading without references? How said that I suggest implementing copy constructors and operator overloading? In my view, non-trivial constructor is original sin of C++ language. It begot exceptions and the rest of the mess followed. |
| Paavo Helde <eesnimi@osa.pri.ee>: Nov 18 02:51PM +0200 18.11.2022 11:40 Juha Nieminen kirjutas: > After all, for example the syntax 'a[b]' is just syntactic sugar for > '*(a+b)', and thus the former is "unnecessary" and could just be dropped > off. It seems other people have agreed with this idea, resulting in things like: while (*(bord+*(*contur-1)-upp)==ncus && (*(*contur-1)-tper2<0 || *(*contur-1)-tper2>(ntpertper-1) || *(bord+*(*contur-1)-tper2)!=ncus) && *temporal!=*(*contur-1)) { *(*contur)=*(*contur-1)-upp; (*contur)++; } Unfortunately, these is a copy-paste from real code :-(( |
| Michael S <already5chosen@yahoo.com>: Nov 18 05:11AM -0800 On Friday, November 18, 2022 at 1:23:10 PM UTC+2, Michael S wrote: > overloading? > In my view, non-trivial constructor is original sin of C++ language. > It begot exceptions and the rest of the mess followed. In post above, please mentally replace DRM with DMR. |
| JiiPee <kerrttuPoistaTama11@gmail.com>: Nov 18 06:32PM +0200 On 18/11/2022 14:51, Paavo Helde wrote: > (*contur)++; > } > Unfortunately, these is a copy-paste from real code :-(( A lot of stars :) |
| T <T@invalid.invalid>: Nov 17 04:39PM -0800 On 11/17/22 07:21, Alf P. Steinbach wrote: > of Microsoft's endless bug introductions, partial bug fixes and willy > nilly changes of things, and I don't even try that any more, so. > - Alf wmic won't tell you mirrored status. Only Diskpart. |
| 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