Compiler moving to faster micros?

[Ecoli-557]

Hello All-
I have greatly enjoyed learning and working with this compiler, thanks to All who had a hand in it.
I am working on a digital audio project and in it I wish to use a CODEC and it needs a proc with a higher clock such as ARMs or STM32s.
I am wondering if there is any desire/interest/direction in having a compiler which will work in this higher speed procs area?

[RGV250]

Have you looked at 16 bit PICs, they are pretty fast.

Bob

[trastikata]

For DSP it is worth exploring the MAC instructions and the overhead-less loops. FFT can be extremely fast, but to achieve that will require some efforts understanding Assembler.

If you think of employing faster MCU's because of the readily available libraries using high-level commands, this could be very inefficient way to do it, but much easier of course.

[Fanie]

If I do a digital audio project I would rather use a chip dedicated for this type of processing and use the pic to control that.  While it is possible to do anything with a micro, is it worth the time and frustration ?

32 bit has become a standard for many things...

[top204]

When I get the time spare, I am looking at an Arm M0 compiler version. However, this is not something that is knocked up over night. It takes months of dedication and absolute concentration, which does not earn any money, and after that work, the compiler may not make a penny, so months of my time wasted!

It is not the sort of thing that can be done in the evenings of over the weekends either, becuase it is sooooo complex. I am busy studying the Arm M0+ PIC32 architecture when I get the chance to do so. Then there is the code generator functions (many hundreds of them) in the compiler, and the arithmatic and logic functions, that are different to standard devices.

The list goes on....

[JonW]

How long do you think it will take to develop a basic version with IO/register manipulation, clocks, and procedures?

This approach could open it up to user-built functions like the Arduino libraries. This would ease the burden and help promote and develop the compiler.

If you do this and get a basic version running, you can then start an internal Posotron-M go-fund page where we (as users) can support you. At that point, if anyone has a specific or custom function that needs a dedicated command, you can charge for it on a one-off basis or get multiple payments from many users to support the development.

[top204]

It is still early days Jon.

I have a few of the PIC32CM5164JH01032 devices,and I am working with them. They are M0+ architecture, and I can get them to power up, and write some code for them in assembler, which is always the first start, as I need to know how the assembler program works as well. But microchip have nicked the 'open source' GCC compiler/assembler that are also used with the dsPIC and PIC24 devices (and put their name to it), so that is one hurdle that is not as big.

32 bit has become a standard for many things...

Only for those who follow... Not for the creators that get the very best out of what they have. The American way (sorry USA friends), is to make things bigger and bigger, so less work has to be done to get something working, at a cost of waste, and to persuade the followers that "this is what is needed", so they can cash in. A standard example, of many examples, are the PCs and operating systems now? They are not much different in operation to the original ones, but the wastage in them is staggering, and it is the wastage in the O/S that makes them a lot, lot slower than they should be if they were written with more care.

[trastikata]

Not for the creators that get the very best out of what they have.

A very interesting article to support this statement, if you have time, read it to the end.

https://jontio.zapto.org/hda1/dsp.html

[top204]

That is an excellent page Dyanko, and one I fully agree with. Reading his other pages, shows he is one extremely intelligent person. Way above my head with all of his calculations and QAM modulation etc... :-)

The newer 18F K and Q devices are inexpensive, swapable, and very flexible, and the newer 16-bit dsPIC33CK devices have more than enough RAM and flash memory for a microcontroller, and operate at 100 MIPS, with built in DSP hardware.

For the standard 'microcontroller' application, they are way more than is actually needed, because DSP is not required most of the time, and they can toggle and monitor pins extremely fast, and the 16-bit operations, with built-in divide, and multiply, and single clock cycle shift, mnemonics, means that arithmetic and logic operations are performed in them extremely fast. Not to mention the plethora of on-board peripherals, and the useful DMA. However, setting up the DMA can sometimes take more time that the actual use of it, unless large lumps of data are moved around. "Blitted" I think they call it :-)

Large chunks of RAM or flash memory are really not needed in most 'microcontroller' applications, and it is normally sitting there being wasted and taking extra current to do nothing, or flash an LED, or display "Hello World" on an LCD, or monitor a sensor, or two, and store or transmit data. All of which can actually be done comfortably with a small 8-bit device. :-)

For a hobby project or a demo, the faster and bigger the better because it "looks good". But for most "real" microcontroller applications, it is wastage that costs, either in the device price and its surrounding components and design because of its speed, or the power to it etc...

On a side note... As an experiment, I used the DMA on a dsPIC33 device to transfer flash memory data to a colour graphic LCD, and it was very, very fast. So I am going to investigate DMA a bit further when I get a chance.

[Fanie]

32 bit has become a standard for many things...

Only for those who follow... Not for the creators that get the very best out of what they have. The American way (sorry USA friends), is to make things bigger and bigger, so less work has to be done to get something working, at a cost of waste, and to persuade the followers that "this is what is needed", so they can cash in. A standard example, of many examples, are the PCs and operating systems now? They are not much different in operation to the original ones, but the wastage in them is staggering, and it is the wastage in the O/S that makes them a lot, lot slower than they should be if they were written with more care. 

I agree.
When the covid fiasco was in full swing, we couldn't get pics here.  I wasn't going to let my client down and the ESP32-S3 was freely available, so I used that.  I used the 18F45k20 before, and it performed fine and was more than sufficient for the needs at the time.
The customer came back and said he wants me to use the ESP in future.  He liked the way it looked on the board and because he can now say there is a 32 bit processor in it.  As you rightly say, a waste of resources. 
I have however added other functions to the ESP's board for (hopefully near) future expansion and here the ESP will shine.
Also had zero comebacks with the ESP, while with the pic boards we had a few.
Something I do like about the ESP32-S3 is the larger pins, it makes assembly a lot easier.  I made the prototype board and it programmed and worked the first time.  I got the LED not only to blink, but dimmed it too.  Very impressed with myself that a 32-bit micro can do that with an LED 
As for the O/S in PC's, the latest is stupid retarded, especially the memory management is pathetic.  I have to restart my SE drawing program from time to time because the O/S limits the memory it can use, while half the total memory is unused, and setting it in task manager has no effect either.  Makes the I7 performs worse than the I3 on win7 
That is one thing "includes" do, it has to cater for various author's functions, the same way the O/S is created by various author's, and it becomes plump and fat.  A bit like the phones we have, they can do everything except make a proper phone call.

[flosigud]

Are these 32 bit micros really faster than 100 mips PIC? I'm not sure when you take into account all the hardware. Few years back I saw a comparison between few 32 bit micros and a 16 mips 16 bit PIC. The PIC lagged behind in all categories but multiplication where it was above average. A 100 Mips PIC would have aced the competition.

Now it seems to me that majority of Positron users stay with 8 bits, so in my opinion more support for the 16 bit hardware would be more useful. At lest for me.

[Fanie]

If you can believe AI...
The ESP32-S3 boasts a dual-core Xtensa 32-bit LX7 microprocessor with a clock speed of up to 240 MHz, offering a significant performance boost over earlier ESP32 models. It also supports Wi-Fi (802.11 b/g/n) at 2.4 GHz with a 40 MHz bandwidth and Bluetooth Low Energy (BLE) with various speed options, including 2 Mbps PHY for higher data throughput. The ESP32-S3's PSRAM/FLASH throughput is also improved, reaching a maximum of 240 MB/s, a 6x increase compared to the standard ESP32.

Xtensa® dual-core 32-bit LX6 with 600 MIPS (in total); 200 MIPS for ESP32-U4WDH/ESP32-S0WD (single-core variants); 400 MIPS for ESP32-D2WD

There will always be another coming from somewhere that is faster, it's a never ending competition.
I like to think more in terms of how easy and will it do what I want for how inexpensive.

Let me add.  These 32 bit micro's use the same instructions as the 8 bit.  To optimize the 32 bit capabilities, a new instruction set will have to be developed to fully use the full capability.  THEN it will be really fast.