Firmware v18.03 - Lines of Code

Toopy14

Axe-Master
Not sure if there is a simple answer to the first question...but how many lines of code are in the v18.03 firmware? What language(s) is it written in? How many programmers are there?

Thanks
 
I would say most likely it's written in C/C++ (maybe minor parts in Assembler). Analog Devices offers a development environment for these languages for their TigerSHARC processors.
 
I would say most likely it's written in C/C++ (maybe minor parts in Assembler). Analog Devices offers a development environment for these languages for their TigerSHARC processors.

That's what I was thinking as well. I developed and teach an Embedded Networking course, using a Microchip development board. I have my student's connect a motor to it, which they then write code so they control the motor via web interface and the web interface provides real-time feedback...really cool stuff. We use C, HTML, Ajax and Javascript.

I've never heard of the TigerSHARC development environment you mentioned. I'll have to look into it. We MPLAB IDE, from microchip, with their C18 compiler, which was free for student's.

One of my student's was hired by Bryston, which makes amps as well as other products. The student designed and developed the firmware to control a rack mounted MP3 player for them...they hired him after they saw it!
 
Why do you want to know? Gross Geek curiosity or something more sinister?
Is someone planning a worldwide AXE virus to takeover concerts everywhere and subject millions of listeners to subliminal messages hidden in sweet guitar tone?
 
Not sure if there is a simple answer to the first question...but how many lines of code are in the v18.03 firmware? What language(s) is it written in? How many programmers are there?

Thanks

There are 2 lines of code. They are;

ARRRRRGHHHH WHOLLY SHAT!!!!!!
FRERRRGGRGRGRRR UMMMS

Written in Blim Blam Zim Zam Zook
A language based on NUNYABZNEZ
 
This is a shunt :D

000011101000111100001111100000000000011111111111110101011010000000000000111111111111111111111111111111111110000000000000000001111111110001111101000101111101101011010101001010100111010101010101010101010101001010100111110010101010101000111110100101010010100010111110101010101001010100101010011010101011110010101011010101100001111111111111111110000000000110100101010101010110101101010110101010101011111101010110100000001101010010101010001001101010110101010101010101011010100101101010101011010101010110101010101101101010101010101
 
- Cliff: As far as DSP programming goes: C and C++ are very similar however you typically have to resort to some amount of assembly programming to get the algorithms to run efficiently. / The Axe-Fx was programmed in C and assembly. Assembly is still a necessary evil to get the most performance from a DSP. The C portion of the code was written object-oriented which C doesn't support inherently but was done using structs for objects. A little more difficult to program than C++ but results in smaller binaries and therefore smaller memory footprint. Like I said before, modeling is very difficult and I could fill a book on the subject. I recommend starting with delays and filters as these are the foundation for everything else. The effects section of this website is actually a pretty good resource. Diving into modeling first is like trying to build a house without ever having used a hammer or saw. There's very little published on the subject of modeling. I've filled three engineering notebooks to date but haven't published anything. The only guy I know doing any sort of publishing on the topic is Julius Smith from Stanford. To do it properly you need to understand the maths. The classic text is Digital Signal Processing by Oppenheim and Schafer. There are several other excellent texts on the subject. Understanding the DFT and z-transform are crucial. Don't listen to people telling you to use anything other than C or C++ (and Assembly where necessary). These are the de-facto languages for a reason. Things like ChucK and Nyquist are inefficient, incomplete and immature. They are useful for trite tasks but totally unsuited to serious applications. Matlab is good and I use it all the time for algorithm testing and visualization but it doesn't really port well to C/C++ and the Matlab compiler is incredibly inefficient since Matlab treats everything as doubles.

- Cliff, TGP: There's no question that modern compilers are much improved. However, a compiler doesn't understand that the fastest algorithm isn't always sonically the best. Finite-register length effects are something very few programmers understand and the order in which you do things has an effect on the resulting audio quality. Most programmers just think "it's floating-point, I don't need to worry about register length". Furthermore I've yet to see a DSP compiler that can match hand-coded assembly in performance. This is likely because DSPs are inherently short-pipeline devices with limited branch prediction. I don't do much general-purpose CPU programming so I have no comment on the efficiency of modern compilers for those devices. I have done extensive tests on the DSPs we use and the hand-coded assembly is always faster, smaller and better.

- Cliff, TGP: What I do is write the framework and UI in C (I actually use an object-oriented version of C that I developed. It has the OO aspects of C++ but results in a smaller footprint and faster execution). All low-level functions like filters are written in assembly and called from the C framework. The actual user input is handled by a separate microcontroller. Register length is the length of the registers in bits. IEEE floating-point is 32 bits and most floating point math is done at this length. Double-precision is 64 bits but takes much longer so it is rarely used. Single precision is fine if you understand how to use it properly. F.e., if you add a large number to a really small number the really small number is essentially lost and the audio quality can suffer. Consider y = a + b - c. Most people would add a to b then subtract c. However if b is really small the proper way to do it is subtract c from a then add b. This is a grossly simplified example but illustrates the basic concept. A compiler has no way of knowing the relative magnitudes of the numbers and therefore can't make a decision on how to commute the operands. How does DSP power of Axe, 11R, Pod HD compare? - Page 3 - The Gear Page

- Cliff: I've yet to find a compiler that can come anywhere even remotely close to hand-optimized assembly. Typically an assembly routine will run at least a few hundred percent faster. The downside is that assembly is a bitch to write and debug. I'm amazed though at how bad many programmers are at optimizing even high-level code. Simple things like moving divides outside of loops or reducing memory fetches they don't even understand. The speed of modern processors has made programmers lazy. We're using 3 GHz computers with 2GB of RAM that run no faster than an old Apple Mac for many tasks (much of the Mac code was written in assembly). Software bloat has become a real problem IMHO. I've spent countless hours testing functions to improve throughput and reduce footprint. Something programmers no longer do. All they care about now is meeting the spec's and moving on to the next project. I suppose optimizing code isn't very glamorous or rewarding though.
 
Back
Top Bottom