What programming language is used for programming ...

[maki]

of hardware devices, DSP units, keyboards etc?

[Kingston]

C, C++ and several forms of assembly languages.

http://en.wikipedia.org/wiki/C_(programming_language)

http://en.wikipedia.org/wiki/C++

http://en.wikipedia.org/wiki/Assembly_language

[maki]

C, C++ and several forms of assembly languages.

http://en.wikipedia.org/wiki/C_(programming_language)

http://en.wikipedia.org/wiki/C++

http://en.wikipedia.org/wiki/Assembly_language

What is the "production line"? Can an C++ file be used directly to burn a ROM in a chip?Or somebody has to rewrite everything in assembler?

[mistertoast]

C, C++ and several forms of assembly languages.

http://en.wikipedia.org/wiki/C_(programming_language)

http://en.wikipedia.org/wiki/C++

http://en.wikipedia.org/wiki/Assembly_language

What is the "production line"? Can an C++ file be used directly to burn a ROM in a chip?Or somebody has to rewrite everything in assembler?

C compilers meant for embedded systems have linkers that can deal with generating code that can go to ROM.

[vonRed]

C compilers meant for embedded systems have linkers that can deal with generating code that can go to ROM.

GCC will do it, it's used in that capacity a lot. You just have to write your own startup file in assembly to intialise the stack etc. and create your own linker scripts.

[Kingston]

you basically code as you would on native platforms, but with lots more limitations to take into account with memory usage, bitdepths and datatypes. Then you compile the code into whatever format those sharc or motorola chips (most common in audio DSP) and their BIOSes expect, and flash them in. This part is usually quite transparent to the coder as the dev platforms for these tasks are very advanced these days. (I've used some sharc IDE and it was much like any other IDE)

These days there are a few synths and digital mixers that run (at least partly) on linux and coding for them is very much like it is on native platforms. You end up with "softsynths" and "plugins" for whatever proprietary formats the OS expects.

[mistertoast]

C compilers meant for embedded systems have linkers that can deal with generating code that can go to ROM.

GCC will do it, it's used in that capacity a lot. You just have to write your own startup file in assembly to intialise the stack etc. and create your own linker scripts.

Yeah. I keep meaning to write a game for MAME or for a Sega Genesis emulator. That's pretty much how you do it. I think there are some example startups around.

[funkadil]

Isn't it ever from the ground up? chip design --> it's own assembly language --> it's own integrated memory. Like in high end reverbs arn't the chips designed to do that job very efficiently. I thought that was why it's so hard to reproduce the quality of hardware reverbs in computer software.

[mistertoast]

Isn't it ever from the ground up? chip design --> it's own assembly language --> it's own integrated memory. Like in high end reverbs arn't the chips designed to do that job very efficiently. I thought that was why it's so hard to reproduce the quality of hardware reverbs in computer software.

I can't imagine it ever happens that way nowadays.

[funkadil]

What sorts of chips do DSP cards use?

[Xenakios]

Isn't it ever from the ground up? chip design --> it's own assembly language --> it's own integrated memory. Like in high end reverbs arn't the chips designed to do that job very efficiently. I thought that was why it's so hard to reproduce the quality of hardware reverbs in computer software.

It probably wouldn't be too hard nowadays. IMHO, it just happens to be so that the companies owning the best algorithms for reverb (like Lexicon and TC) don't want them flying around freely as Intel/PPC/etc-code, as that would make it a lot easier to reverse engineer how the sound processing is made up. And of course, there is the piracy issue...Not really in the hardware makers' interests...

-X

[Kingston]

What sorts of chips do DSP cards use?

most commonly,

http://www.google.fi/search?hl=fi&clien ... =Hae&meta=

http://www.google.fi/search?hl=fi&clien ... =Hae&meta=



there's a few other major DSP chip manufacturers (analog devices for one), and indeed occasionally it happens that a company designs their own audio DSP chip from ground up:

http://www.fairlightau.com/default_content.html (for example)

or sometimes a company scores a very powerful processor originally designed for other tasks than audio. The UAD-1 is a rather famous case of this as their card is powered by a specialised video accelerator chip.


and sometime in *very* near future we'll be able to completely unlock all those nvidia and AMD/ATI turbo GPUs for audio and general DSP usage. It's already happening actually, but the current solutions are very rough on the edges.

[whyterabbyt]

Isn't it ever from the ground up? chip design --> it's own assembly language --> it's own integrated memory.

Sometimes; there are a few companies around there with proprietary hardware; however I suspect a lot of that is hardcoded for very specific functions, and, I'd suspect, used in conjunction with something more generic.
Expect a lot of that stuff to be programmed in assembler, if its programmable; even if the company were able to port something like the GCC backend to their own hardware, a generic compiler wouldnt be able to optimise code as well as a talented human, and you'd probably need that human and a couple of his clones to even start working on a decent implementation of those optimisations for a compiler.

Like in high end reverbs arn't the chips designed to do that job very efficiently.

At least the common operations involved, yes; almost certainly on a heavily-parallelised basis, ie lots of the same operation all happening at once...

I thought that was why it's so hard to reproduce the quality of hardware reverbs in computer software.

Not really. I think its more to do with the fact that these companies have teams with hundreds of man-years of experience, a codebase to match, and are working on refinements of algorithms most programmers will never get to hear about.