Do you care what architecture your MCU/MPU implement? Why? - Page 1
Forum section: electronics / general

author: romhunter
author_rank: Regular Contributor
timestamp: October 27, 2020, 06:28:43 pm
content: Just want to know what engineers think about it.I've worked with RISC-V ASIC before, and despite all the hype going on, I just considered it to be another architecture. So for me the answer is No.

author: tom66
author_rank: Super Contributor
timestamp: October 27, 2020, 06:53:43 pm
content: Yes. It influences coding style and optimisation.For instance, on most modern ARM processors, knowing that Operand2 can be used to quickly load certain constants influences constant choices, and instructions that support combined ALU operation+shift informs me of the design of code manipulating bitfields. Then, at higher speeds, you need to start understanding caching behaviour and architecture there.While there is a level of 'just let the compiler get on with it' you need to give the compiler something useful to work with to have good results.

author: ataradov
author_rank: Super Contributor
timestamp: October 27, 2020, 10:11:34 pm
content: I care that it is generally not some stupid stuff from 40 year ago. Like I would not work with Big Endian stuff. All my code is hard coded for LE, and I don't really care if it makes someone else's life harder.I also care that there are widely available and cheap programming/debugging tools and programming interfaces documented.But generally in a grad scheme of things, no I don't really care.

author: tggzzz
author_rank: Super Contributor
timestamp: October 27, 2020, 10:19:06 pm
content: I don't care about the ISA.I do care about what the ISA and the implementation of the ISA guarantee.For example, are there anyhardreal-time guarantees, i.e. the maximum length of time that a code sequence will take to execute under all circumstances.

author: hans
author_rank: Super Contributor
timestamp: October 28, 2020, 09:28:15 am
content: To some degree... depends on the design.If you want to work on hard silicon, I don't really care that much. I'm more concerned with tools, peripherals, memory size and layout (for e.g. DMA), cost and power consumption.If you want to work on custom CPU designs for an application e.g. by the use of custom instructions or accelerators on the memory bus, then yes several open source implementations are very nice to have. You can make it work with softcore tools from FPGA vendors, but they have been clunky at best in my experience.

author: Berni
author_rank: Super Contributor
timestamp: October 28, 2020, 10:23:55 am
content: The instructions set not so much. More the features.There are obviously differences between writing code for a dinky little 8bit MCU with a single register or for a 32bit ARM with FPU. Can make for drastic differences on how expensive certain operations are, same with interrupts. But in general when it comes to differences between various 32bit architectures they are mostly the same thing.The differences mostly come in the form of other hardware and peripherals. Some have great simple and high performing peripherals, some have crappy overly complicated crappy peripherals that come with errata the size of a phonebook.

author: AndyC_772
author_rank: Super Contributor
timestamp: October 28, 2020, 10:34:35 am
content: Yes, I do care, because limitations in the architecture can influence the code at a higher level.For example, some PICs (all?) use a different instruction to read data from Flash storage vs RAM. This means that if, say, you have a function which reads a string and transfers it to an output port, you simply can't use the same function to output string constants (from Flash) and strings placed in RAM. The compiler will throw an error.To work around this, you either need:- two functions, one of which takes a pointer to a string in Flash as an argument, and another which takes a pointer to a string in RAM, or- to copy strings from Flash into RAM first, as a separate and otherwise entirely unnecessary operation.Another potential issue is with paged memory. Suppose you have an MCU whose memory is mapped as A banks of B kbytes each. Can you have an array that's 2B kbytes long? Quite probably not - and even much smaller arrays must each be contained within a single page.

author: tggzzz
author_rank: Super Contributor
timestamp: October 28, 2020, 11:18:35 am
content: Quote from: blueskull on October 28, 2020, 09:35:06 amAverage or worst case interrupt latency? If average, why?

author: GromBeestje
author_rank: Frequent Contributor
timestamp: October 28, 2020, 12:24:20 pm
content: I'm mostly concerned with the features and caveats the architecture offers, and the supported toolchains.If it is some proprietary architecture that I can only use with a weird compiler, then it is a no-go, even if the architecture would have advantages over the more common architectures. I prefer to use a GNU compiler. This offers a free compiler with modern C support. I don't want to be stuck at C89, or any weird C dialect.Furthermore, I wish decent debugging support. Preferably SWD or JTAG, supported by OpenOCD, but otherwise SEGGER support would do (and then cJTAG is also an option) If any proprietary debugging interface, there should be decent software, preferrably open source, but at least linux support, and capable of working with GDB.It's not all about the architecture per se, but it is about the development environment. How well does it integrate with existing tools. Having gcc and gdb support makes it easy to integrate. I prefer to use the same IDE regardless my target MCU.Yes, the features and caveats of the architecture are important. But being able to write code for the target, program and debug the target come first.Edit: In addition:For an MCU target. I guess, I care more about the available peripherals, and how those peripherals are interacted with (eg, DMA support). Some MCUs offer memory-to-memory DMA, others don't. That kind of things, I guess, matter more then the core.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: October 28, 2020, 12:54:58 pm
content: I'm very apprehensive to use any uC if it does not have GCC ported to it. (Maybe SDCC for small projects is acceptable, such as the FX2 firmware as used by the Sigrok project)Further, you've got to know some details about your architecture.For example, the AVR's having 32 registers for a small 8-bitter is nice and all, but not so if you want to use an RTOS, and have to save all those registers on each task switch.If the complexity of a projects warrants use of an RTOS, then you will want a decent interrupt controller with configurable priorities.20% speed difference between Risc-V or ARM is mostly irrelevant.If you need more horsepower, just use a CPU with 5x the clock speed and 10x the memory for an extra Euro or so. The availability of floating point instructions can be important, etc.On the simple side Risc-V has the potential to be cheaper then ARM, but I'm guessing that ARM has done a lot for GCC and paying a few cents of royalties for each uC is well worth it.Also, It takes quite a bit of time for me to get used to a certain set of peripherals.20 years ago the AVR microcontrollers were wonderful. They were one of the first with GCC, while most others were still in the assembly era (BASIC is simply no option) I started to dislike the AVR microcontrollers later. Each variant has different timers. Even within a single uC the timers are different. Then there is the horrible USI, the Tinies implement I2C very differently from the Mega's, etc. When I switched to arm, there was a description of a timer in the datasheet, and a line that said: "There are 7 of these timers in this chip".On the AVR's I sometimes looked through the ASM listing to see what GCC made of my C code. Changing the way you write your C statements can have a measureable effect on code size and execution speed. Mostly it's low percentage differences, but sometimes you have unexpected bloat you want to avoid. For example, adding a function call in an ISR was very expensive on AVR's because it triggered lots of register pushes and pops for the ISR itself.It's educational to keep an eye on this, even if you do not know much assembly. And after a while you build some experience and know which constructs work and which don't.

author: tggzzz
author_rank: Super Contributor
timestamp: October 28, 2020, 02:18:50 pm
content: Quote from: blueskull on October 28, 2020, 01:18:08 pmAnd how do predict (or otherwise determine) the maximum interrupt latency? What are the assumptions you have to make?

author: tggzzz
author_rank: Super Contributor
timestamp: October 28, 2020, 02:41:27 pm
content: Quote from: blueskull on October 28, 2020, 02:30:08 pmThere are a lot of "ifs" there - and it isn't clear that they can be met in practice.When an "important" interrupt arrives, consider:normal code being in a critical sectionanother interrupt being in a critical sectioncode/data being in/out of a cachecaches in the process of being flushedmore than one "important" interrupt which has to meet hard realtime guaranteesthat you haven't missed somethingHow do you document your presumptions and your conclusions?How do you ensure the presumptions are valid, and continue to be valid?

author: woofy
author_rank: Frequent Contributor
timestamp: October 28, 2020, 03:02:02 pm
content: I answered "no" because I'm closer to no than yes, but the question is too black & white. The truth is I do care up to a point. It has to have the performance to do the job. That's mostly down to experience and wet finger to the wind. When choosing a controller for a design the primary motivator is cost. I usually start on Microchips website with their full product parametric searchhttps://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1005. Enter the requirements and choose the cheapest chip that does the job. Beyond that, I don't care if its PIC16,18,24,32, AVR, MIPS, ARM or whatever. Just so long as there is a C compiler available.

author: tggzzz
author_rank: Super Contributor
timestamp: October 28, 2020, 03:08:11 pm
content: Quote from: blueskull on October 28, 2020, 02:46:28 pmAh, back to the 1980s, in other words.Except that if CM3 is the RPi Compute Module 3, its BCM2837 processor is an ARM A53 8-stage dual issue processor with 4 cores and shared caches, plus virtual memory bringing TLB misses and paging. Good luck making any timing predictions with that!

author: Howardlong
author_rank: Super Contributor
timestamp: October 28, 2020, 03:20:03 pm
content: Depends.To add to what's already been said...There is a cost in terms of training and tool chain familiarisation, so jumping ship to an unfamiliar architecture is never free. The maturity of toolchains is important, you don't want to waste time debugging the debugger on an unfamiliar ecosystem. It's very common that I am interested in the disassembly view to see how I might analytically improve performance of algorithms based on what the compiler's generated, and very occasionally I'll dip into assembly language if necessary on the rare occasions the compiler makes a pigs ear of it and I can't manipulate it into my way of thinking. Remember, unlike you, compilers for MCUs don't generally have much of a clue about your data.A lot of my work is in coin cell powered devices, so I'm also interested on how architectures behave, including raw low power current draw and instructions per clock. Even things like a requirement to add an external regulator might influence my choice, so reasonably wide operating voltage is also typically a requirement.

author: Howardlong
author_rank: Super Contributor
timestamp: October 28, 2020, 03:24:05 pm
content: Quote from: tggzzz on October 28, 2020, 03:08:11 pmAs far as I'm aware, that's a SoC, not an MCU.There are definitely issues around determinism in some Cortex-M and other MCU implementations like MIPS to do with flash wait states, pipeline stalling, cache, virtual SDIO memory, AHB contention etc, however these are usually simple to work around and tweak if necessary to maximise impact. For example, you probably would want to avoid running an ISR off a memory region on SD card. For maximum performance, you might want to choose a zero waitstate RAM region for your ISR.

author: madires
author_rank: Super Contributor
timestamp: October 28, 2020, 03:31:13 pm
content: For low level stuff I care about the architecture because it determines how the MCU works and what I can expect from it. For high level software (above OS) not so much.

author: BravoV
author_rank: Super Contributor
timestamp: October 28, 2020, 03:33:45 pm
content: Question, say you're an employee, and the bosssaidordered you to use X MCU/MPU which you hate "AND" you know and used it before, and no excuse.What would you do ? Resign ?

author: madires
author_rank: Super Contributor
timestamp: October 28, 2020, 03:37:46 pm
content: Quote from: ataradov on October 27, 2020, 10:11:34 pmIf you do a lot of networking you might prefer big endian (= network byte order).

author: Bud
author_rank: Super Contributor
timestamp: October 28, 2020, 03:39:57 pm
content: I do not care because there is nothing i can do about it.

author: ataradov
author_rank: Super Contributor
timestamp: October 28, 2020, 04:14:29 pm
content: Quote from: madires on October 28, 2020, 03:37:46 pmNot really. You don't do networking for networking sake (unless you are working on the actual network equipment, of course).And all the application level stuff is still LE in my case. Obviously you have to power though the BE stuff on the lower level.And the only real reason networking is BE is because it is 40+ years old.

author: Howardlong
author_rank: Super Contributor
timestamp: October 28, 2020, 04:53:17 pm
content: Quote from: BravoV on October 28, 2020, 03:33:45 pmThis could be anything, for example I've just been re-assigned from my contracted project to migrate an application from Flash based technologies (Flash is unsupported after December this year). Until this migration, I had zero experience of the technologies behind Flash, nor did I particularly want to know; I certainly have no desire to do UIs, been there, done that, I don't enjoy it. You just have to learn fast, even though you know it'll be discarded knowledge. Nobody gets prizes for pushing against the grain. What you do get hired for is your expertise and experience in particular areas. A reasonable breadth of knowledge shows you're not a one trick pony, although I accept this is often overlooked particularly by HR drones.

author: ataradov
author_rank: Super Contributor
timestamp: October 28, 2020, 05:00:59 pm
content: Quote from: BravoV on October 28, 2020, 03:33:45 pmI guess it depends on a specific situation of a person.Me personally - yes, resign, if there is no possibility to re-negotiate that somehow. Or set the explicit time frame for the project completion. And if the situation repeats, then I'm gone, for sure.One of the job requirement from my side is to work with the technology that I enjoy and that will keep me up to date with the current hardware and employable elsewhere. Otherwise it would be just one of those nightmare jobs that people hate, but have to do because they need the money. I prefer to not be in that situation.Having financial security helps here, and one of the reason I personally build that security.

author: guenthert
author_rank: Frequent Contributor
timestamp: October 28, 2020, 07:29:18 pm
content: Quote from: ataradov on October 27, 2020, 10:11:34 pmSome architectures are still bi-endian (including Arm64). Solely big-endian seems to be only SPARC, but that's still current (even if a bit of a niche).Quote from: ataradov on October 27, 2020, 10:11:34 pmHmmh, I find that software engineering goes inevitably the same way as e.g. physics or other sciences: the relative significance of of the contribution of individuals shrinks and progress depends more and more on team effort. It's been more than 40 years since the Woz single-handily created the Apple I including system software or that Knuth wrote TeX or Jonathan Sachs's wrote Lotus 1-2-3.Embedded systems using MCUs might be the last hold-out of programmers not working in teams. Enjoy it and your attitude while you can.

author: ataradov
author_rank: Super Contributor
timestamp: October 28, 2020, 07:38:31 pm
content: Quote from: guenthert on October 28, 2020, 07:29:18 pmThat is fine, and long as it defaults to LE and most people use it that way.I habe never seen anyone use or want to use BE ARM.Quote from: guenthert on October 28, 2020, 07:29:18 pmOr I can just reach high enough level where I have enough of an input on what the team is doing.BE is pointless. There is not even really a need to have this discussion now, since it is so irrelevant in modern times. Most of the stuff is LE and all new stuff is LE, at least by default.

author: madires
author_rank: Super Contributor
timestamp: October 28, 2020, 08:16:39 pm
content: Quote from: ataradov on October 28, 2020, 07:38:31 pmI agree, it's irrelevant in many cases. However, for networking applications big endian provides a performance benefit because the addressing matches the network byte order. Little endian systems have to reverse the byte order, first time when receiving a request and a second time when sending the reply. Therefore you can achieve a lower latency with a big endian system.

author: tggzzz
author_rank: Super Contributor
timestamp: October 28, 2020, 09:34:49 pm
content: Quote from: blueskull on October 28, 2020, 03:50:30 pmIrrelevant, of course. Interesting, but irrelevant.QuoteThe problem isn't the speed of the cache nor the latency. The problem is the jitter (and potentially a large jitter) when cache misses occur.I know the i960 allowed the cache to be nailed down. Which modern processors enable that?

author: tggzzz
author_rank: Super Contributor
timestamp: October 28, 2020, 09:40:24 pm
content: Quote from: Howardlong on October 28, 2020, 03:24:05 pmThe distinctions are blurry, of course, but yes.I was more than a little surprised that blueskull mentioned the RPi CM3 and 8051 together, and implies that equivalent techniques are applicable to both. As far as I'm concerned, that's a red flag.QuoteJust so.Even more so with the Cortex-A series!Predicting and guaranteeing hard realtime performance is a surprisingly difficult problem to get right. It sounds easy, until you start thinking of the edge cases. I've seen similar lack of understanding when it comes to time and dates.

author: brucehoult
author_rank: Super Contributor
timestamp: October 29, 2020, 07:04:54 am
content: Quote from: blueskull on October 28, 2020, 02:46:28 pmThat's nothing to do with the instruction set.There are RISC-V cores with all your desirable properties.The new Microchip "PolarFire SoC" FPGAs, for example, give you five 64 bit RISC-V cores. Four of them are for running Linux and have cache and FPU and branch prediction and so forth to increase throughput. The 5th core doesn't have FPU, can have branch prediction turned off, and has tightly-integrated SRAM instead of cache.You still get to program on a modern instruction set with plenty of registers and good compiler. Other than FP, it runs exactly the same code as the other cores.

author: tggzzz
author_rank: Super Contributor
timestamp: October 29, 2020, 08:24:00 am
content: Quote from: blueskull on October 29, 2020, 07:12:54 amYes, and that's basically the condition that interests me (although there can be other cases where jitter is important).In previous posts you have mentioned the CM3 (presumably the RPi compute module 3) in this context. How do you assess the worst case for a Cortex A53 multi-core processor with shared caches and TLB (another cache!) misses and paging?You also mentioned "Some of those processors support linker directives to explicitly put certain code into the cache". Which processors (and toolchains) allow you to do that?

author: Berni
author_rank: Super Contributor
timestamp: October 29, 2020, 09:19:29 am
content: Well running things from cache on some big ARMs is a matter of configuring the L2 cache controller to only use part of the cache area while the rest just appears as RAM at some address. Then you just create a extra RAM section in the linker script that is located there. Then put the correct pragma in the code to place that variable or function inside this section. For GCC its something like "__attribute__ ((section ("foo")));"Stick your timing critical code in there and there you go.The jitter still won't be that great since there is is still the L1 cache and the pipeline and such to content with but its going to be pretty quick. If you need more precise timing than that then you are using a hammer for doing the job of a screwdriver.

author: brucehoult
author_rank: Super Contributor
timestamp: October 29, 2020, 09:19:48 am
content: Quote from: tggzzz on October 29, 2020, 08:24:00 amI think every SiFive RISC-V core that taped out less than about three years ago and has cache effectively has this ability. (perhaps some customer might want a core without it but I don't know why you'd want to)The L1 caches correspond to a memory-mapped range. Any write into this range removes the part of the cache SRAM storage from that address to the top of the cache memory range from availability for use as cache, and instead makes it directly available as locked in place SRAM.There are limits on the percentage of the cache you can convert to TIM in this way, so that the cache still had absolute minimum one full way available for cache duties. e.g. a 32K 8-way set associative cache can at most have 7 of the ways locked as direct-access SRAM, with the cache now limited to being a 4K direct-mapped cache.A write to 1 byte past the end of the SRAM memory range releases the SRAM back to cache usage. No off-by-one errors, please :-)In the event that you are running an OS such as Linux on that core, you would of course do this only in machine mode or possibly supervisor mode and use the PMP unit and/or page tables to prevent less privileged software from referencing the wrong things.Then it's just a matter of arranging for the linker to put code or data sections at the appropriate addresses and/or write your own code to explicitly copy it there on demand.

author: tggzzz
author_rank: Super Contributor
timestamp: October 29, 2020, 09:31:07 am
content: Quote from: Berni on October 29, 2020, 09:19:29 amThanks for the pointers.Icompletelyagree with your point about precise timing and hammer/screwdriver.My main interest is hard realtime, which means knowing the worst-case timing for interrupts and any code execution derived from the interrupt. Any contention for any resource causes problems for that.

author: tggzzz
author_rank: Super Contributor
timestamp: October 29, 2020, 09:37:20 am
content: Quote from: brucehoult on October 29, 2020, 09:19:48 amIf I understand that correctly, it could be regarded as "locked-down via design patterns used in my program". That sounds as if it would work, but I would prefer something a little more concrete than such a convention.I would definitely regard having a general purpose OS running on that core as an anti-pattern for hard realtime applications

author: Berni
author_rank: Super Contributor
timestamp: October 29, 2020, 10:20:12 am
content: It is quite common however to add a small "realtime CPU" into big SoC chips for this very task. Its basically a processor from a small 32bit MCU that can access all of peripheral buses and sometimes all of memory too. Some of it is still not quite timing deterministic because the memory bus itself can end up busy sometimes, but it does make timing critical code a lot easier to implement.I remember seeing an example on one of the Texas SoCs way back where they used one of the multiple little CPUs (I think they called them RTU for Real Time Unit) in order to repurpose a audio I/O peripheral (I2S,TDM..etc) in to providing 8 or 16 channels or something of UART. The little CPU was simply using the audio peripheral as a shift register to bit bang UART into a buffer in memory.

author: tggzzz
author_rank: Super Contributor
timestamp: October 29, 2020, 10:39:04 am
content: Quote from: blueskull on October 29, 2020, 10:15:31 amClearly "CM3" is ambiguous and misleading, whereas the extra 6 characters remove the ambiguity.QuoteThat's interesting since the memory can be configured as cache or SRAM. I'd be curious to see how the fixed point and saturating arithmetic is represented in C, but it looks like the end of life is on the horizon.

author: tggzzz
author_rank: Super Contributor
timestamp: October 29, 2020, 11:48:51 am
content: Quote from: blueskull on October 29, 2020, 10:41:35 amI've no idea of any EOL, I merely observe that - at a cursory glance - some toolchain components appear to have not been updated recently.The intrinsics are an obvious way, but I was wondering if there was something less crude.

author: Berni
author_rank: Super Contributor
timestamp: October 29, 2020, 12:08:51 pm
content: DSPs tend to be pretty fiddly to write efficient firmware for in general.For example Texas has there own C compiler for the C6000 family DSPs. As a result it has some compiler specific ways of giving it hints on what to do, but in general you are supposed to write code in certain ways that the compiler understands, so that it can implement various loops and math in a optimized way that makes use of the weird funky parallel ALU and fast loop iteration.But id say DSPs are sort of going towards extinction these days. The modern 32bit processors with SIMD instructions and high clock speeds can now provide enough number crunching grunt for most tasks while higher performance number crunching can now be taken over with FPGAs or GPUs

author: Howardlong
author_rank: Super Contributor
timestamp: October 29, 2020, 01:20:58 pm
content: Quote from: blueskull on October 29, 2020, 12:10:17 pmThat is my experience too, and occasionally vendor algorithms are barely optimised at all even for generic use.One problem for DSP is that we often consider the processes as sequences of logical blocks, relying on memory buffers to store interim results. In some architectures such as in the ARM world, this means you're repeatedly doing expensive RAM load/store operations for those interim results between logical processing blocks, adding non-computational administrative overhead.An alternative is to try to remove most of those repetitive load and store operations by coalescing these logical processing blocks, instead using the CPU register set for small buffers for those interim results, and only using load and store operations once at the beginning and once at the end. This is where a human implementation of an algorithm can easily beat the optimising prowess of any compiler.

author: NiHaoMike
author_rank: Super Contributor
timestamp: October 29, 2020, 01:59:20 pm
content: I only really care about it in terms of compiler support and performance. I rarely program in assembly.Quote from: Berni on October 29, 2020, 12:08:51 pmOr more accurately, DSPs merged with general purpose CPUs and FPGAs. Many high end microcontrollers and all but the cheapest of FPGAs have DSP capabilities. Even modern PC CPUs and GPUs have some DSP specific features.https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation#Support

author: coppice
author_rank: Super Contributor
timestamp: October 29, 2020, 02:15:58 pm
content: Quote from: Berni on October 29, 2020, 12:08:51 pmIf you want DSP code to run fast on those modern 32 bit processors with SIMD, you have at least as much work to do as running those applications on something like the C6000.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 29, 2020, 02:31:43 pm
content: Quote from: coppice on October 29, 2020, 02:15:58 pmWell, I partly agree but it all depends on what you call "fast". If you want to take full advantage of a given CPU with SIMD, then that's right.But I agree with Berni: in many cases, you can do some intensive DSP without caring much for the underlying ISA (I know I have), and you can write code in C or C++ with FP without caring much, which is usually not the case with common DSPs, which, even when using C, usually require specific data types and specific intrinsics, otherwise performance can be mind-boggingly low.

author: Berni
author_rank: Super Contributor
timestamp: October 29, 2020, 02:37:18 pm
content: Yep milking the most performance out of it tends to involve some asembler in the critical loops.For example the offical first party CMSIS DSP library for ARM Cortex families of MCUs has plenty of assembler to do everythyng from summing together arrays to matrix math to doing FFTs, you just call the apropriate function to do the thing you want. Doesn't lean on any compiler magic to get it running fast. But the compilers that have been around for a while have gotten pretty good at optimizing code anyway. They will use CPU registers for shorter lived temporary variables instead of the stack, they will change order of operations if it helps, turn switch statements into jump lists, unroll loops when sensible, cache RAM reads in internal registers...etcBut squezing performance out of older DSP architectures can be much harder. They tend to have memory split into sections to allow parallel access to multiple memory locations in a single cycle, but only if each access it is its own section, so great care must be taken where in RAM things are kept. They have a funky pipeline that can execute multiple instructions at the same time, but the instructions need to use seperate parts of the DSP but are too dumb to do that automagicaly like a modern x86 can, so they have funky assembler instruction placed in just the right order to have them interweave once executed, if they are in the wrong order they might stall and have to wait for something. Even the debugger for these DSPs goes all funky and starts highlighting multiple lines of assembly code in colors as you single step trough it to indicate what part each section of the DSP is working on at the moment You really need to have a deep understanding of how your particular DSP works in order to squeze all of the performance out of it. Impossible for the compiler to do all of this, but they do atempt to help out as much as they can.With modern CPUs with SIMD instructions its mostly just about making sure the data it needs is in the cache and is ordered in a way that fits those wide SIMD instructions.

author: coppice
author_rank: Super Contributor
timestamp: October 29, 2020, 03:07:02 pm
content: Quote from: Berni on October 29, 2020, 02:37:18 pmThe things you describe aren't that big a deal for most DSP algorithms. Those hardware features you describe like they are restrictive were actually tailored to make most DSP algorithms quite easy to map to the machine. Some adaptive processes can be a PITA (e.g. LMS), because the architecture was set up to make them easy to implement and fast, but the documentation to help you understand how they work best is poor.Quote from: Berni on October 29, 2020, 02:37:18 pmGetting stuff in the right places to let the SIMD instructions run efficiently is the Achilles heal of most modern machines. It takes real effort to get it right, and it often saps away most of the gains you get from parallelism. GPU designs tend to take this stuff far more seriously.

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: October 29, 2020, 07:25:17 pm
content: I only care that there's a decent openocd debugger plus GCC / Clang port.Microchip lost my money a long time ago.

author: westfw
author_rank: Super Contributor
timestamp: October 30, 2020, 01:09:57 am
content: QuoteNot much of one. On a modern RISC processor, you're looking at adding a one-clock "swap" instruction to a memory access that probably took ... a lot more clocks than that (on volatile data, so it's not even in cache...) It's nice when there's a compiler that will do that for you, of course.(the big reasons for BE support is "legacy code." And yeah, I'm talking about actual networking equipment.)

author: westfw
author_rank: Super Contributor
timestamp: October 30, 2020, 01:29:50 am
content: So ... some of the times I care, and other times ... not so much. The trick is figuring out whether a given application needs me to care or not!We are spoiled these days, and the raw cpu power and memory available for a small price will mitigate architectural inelegance in many, many, applications.In theory, I am comforted by architectures with a broad range - ARMs than span $0.50 microcontrollers to desktop-class power. In reality, I also get depressed that that Cortex-M0 architecture is about as much like that multicore Cortex-A7x in my cell phone as a 6809 is like a 68040.There are architectural pitfalls that I try to avoid - the main one being banking schemes that prevent the straightforward use of data or code pieces larger than I expect to use. (AVRs and MSP430s up to 64k; no problem. Past that... I get pretty nervous and starting thinking 32bit chips...)(I see a fair number of "can I connect this video camera to my Arduino?" type questions. No! just... No! ("what about a Due?" - still NO!))

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 30, 2020, 02:35:42 pm
content: Quote from: westfw on October 30, 2020, 01:09:57 amYes, this is really a non-issue IMO. That may slightlly matter if the device you're designing doesn't do anything else than networking. And even so, as you said, on any modern CPU, that would still be negligiible.

author: NorthGuy
author_rank: Super Contributor
timestamp: October 30, 2020, 05:14:36 pm
content: Sure I do care about the architecture.It's like asking if you care whether you're driving a dump truck or Ferrari.

author: brucehoult
author_rank: Super Contributor
timestamp: October 30, 2020, 10:54:14 pm
content: Quote from: NorthGuy on October 30, 2020, 05:14:36 pmI don't care much between the nice architectures, of which there are half a dozen at least.It certainly does matter if you want me to write anything substantial on one of the awful ones. Of which there have been far more, historically. Far too many of which still persist.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 31, 2020, 08:46:03 am
content: Give me everything memory mapped to single address space with no segmenting or other tricks, all accessible by CPU with the same instructions, little endian, with enough oomph for the task I'm considering, compiler with guaranteed availability and guaranteed quality (no thousands of catastrophic bugs) and it's all OK. Having GCC available is a plus. Debug capabilities irrelevant.

author: tggzzz
author_rank: Super Contributor
timestamp: October 31, 2020, 08:54:27 am
content: Quote from: NorthGuy on October 30, 2020, 05:14:36 pmIf you want unhelpful analogies, it is Toyota vs Mazda vs VW vs Raleigh vs Brompton. (The latter two are bicycle manufacturers).

author: brucehoult
author_rank: Super Contributor
timestamp: October 31, 2020, 10:15:15 am
content: Hey, don't dis the Raleigh 20 with a flag on a fiberglass pole! They were the cool thing here in unsophisticated 70s NZ.

author: tggzzz
author_rank: Super Contributor
timestamp: October 31, 2020, 10:43:26 am
content: Quote from: brucehoult on October 31, 2020, 10:15:15 amOh, I'm not dissing them! I own a Brompton and it is my preferred way to travel in London: get tired, fold it and take it on a bus/tube/coach/taxi.Horses <ahem> for courses