[quote:c2c1716ed6=*PDT*]Hier ein kleines specki demo.
Bes
Hey....COOL. Vor allem der Anfang mit dem knurzenden Sound
Bes
PDT schrieb:
Hey....COOL. Vor allem der Anfang mit dem knurzenden Sound
Moogulator
Admin
solltest du fast in '*neue Tracks* packen, f
solltest du fast in '"neue Tracks" packen, fürn "DEmo" isses schon zu gut..
solltest du fast in '"neue Tracks" packen, fürn "DEmo" isses schon zu gut..
P
p2xltiger
.
wollte mal fragen, wie's jetzt mittlerweile mit den midi-sac
wollte mal fragen, wie's jetzt mittlerweile mit den midi-sachen aussiehst...ist das jetzt schon im betriebssystem drin?
wollte mal fragen, wie's jetzt mittlerweile mit den midi-sachen aussiehst...ist das jetzt schon im betriebssystem drin?
PDT
..
MIDIseitig gibts momentan nur rudiment
MIDIseitig gibts momentan nur rudimentäres (Die parts lassen sich per midi keyboard spielen und aufnehmen, specki synct auf externe midi clock. Selber gibt er glaube ich noch keine midi signale aus - wird aber auf jeden fall auch bald kommen)
Als nächstes steht glaube ich der Sequencer mit den frei routbaren Sequencerlines auf der liste.
MIDIseitig gibts momentan nur rudimentäres (Die parts lassen sich per midi keyboard spielen und aufnehmen, specki synct auf externe midi clock. Selber gibt er glaube ich noch keine midi signale aus - wird aber auf jeden fall auch bald kommen)
Als nächstes steht glaube ich der Sequencer mit den frei routbaren Sequencerlines auf der liste.
Moogulator
Admin
[quote:8aaf5acfe5=*PDT*][quote:8aaf5acfe5=*Moogulator*]sollt
done http://www.sequencer.de/syns/radikal Spectralis
PDT schrieb:Moogulator schrieb:
wenn du magst kannst du es gerne zu den anderen specki demos auf deiner seite verlinken
done
http://www.sequencer.de/syns/radikal Spectralis
[quote:08bda893bc=*PDT*]Hier ein kleines specki demo.
htt
sehr geil !! ich will auch einen SPECKI !!!
htt
PDT schrieb:
sehr geil !! ich will auch einen SPECKI !!!
und hier noch ein weiteres Appetith
und hier noch ein weiteres Appetithäppchen. Drumgrooves mal etwas dreckiger mit 192th Einsatz in der Drum-Grid und viel Filter-Verfremdung.
Das Drumcomputer Fingersnap-Sample mutiert zu einem Oszillator, wenn man die 192th triggern lässt.
und für die Spectralis User die Pattern auch gleich zum Selbstjammen dazu:
http://www.spectralis.de/demos/Song13.zip
Das erste Pattern, dass man hört ist die Nummer 16, über Solo werden im Verlauf weitere Spuren des Patterns hörbar gemacht!
Natürlich auch hier der Spectralis über die Stereo-Ausgänge direkt aufgenommen und nicht nachbearbeitet...
und hier noch ein weiteres Appetithäppchen. Drumgrooves mal etwas dreckiger mit 192th Einsatz in der Drum-Grid und viel Filter-Verfremdung.
Das Drumcomputer Fingersnap-Sample mutiert zu einem Oszillator, wenn man die 192th triggern lässt.
und für die Spectralis User die Pattern auch gleich zum Selbstjammen dazu:
http://www.spectralis.de/demos/Song13.zip
Das erste Pattern, dass man hört ist die Nummer 16, über Solo werden im Verlauf weitere Spuren des Patterns hörbar gemacht!
Natürlich auch hier der Spectralis über die Stereo-Ausgänge direkt aufgenommen und nicht nachbearbeitet...
W
wqretrhtfsdrtz
Guest
Mal ne andere Frage- aus reiner Neugier: Was f
Mal ne andere Frage- aus reiner Neugier: Was für ein (?) Prozessortyp verrichtet im Spectralis eigentlich seinen Dienst?
Mal ne andere Frage- aus reiner Neugier: Was für ein (?) Prozessortyp verrichtet im Spectralis eigentlich seinen Dienst?
[quote:b653de5faf=*Alisa 1387*]Mal ne andere Frage- aus rein
Du meinst vermutlich, welcher DSP verrichtet seinen Dienst, oder?
Wir setzen zwei Texas Instruments TMS320C6713BPYP200 ein. Das sind Floating Point DSP's mit einer für uns recht nützlichen Performance. Ein DSP macht die Sampling Engine und die Effekte und der andere den Hybrid-Synth und die Filterbank.
Ausschlaggebend für den Klang sind aber eher die Algorithmen als die Rechenkäfer, auf denen sie laufen. Von daher macht ein TI DSP noch keinen guten Synthesizer - verhindern tut er ihn aber auch nicht
Alisa 1387 schrieb:
Du meinst vermutlich, welcher DSP verrichtet seinen Dienst, oder?
Wir setzen zwei Texas Instruments TMS320C6713BPYP200 ein. Das sind Floating Point DSP's mit einer für uns recht nützlichen Performance. Ein DSP macht die Sampling Engine und die Effekte und der andere den Hybrid-Synth und die Filterbank.
Ausschlaggebend für den Klang sind aber eher die Algorithmen als die Rechenkäfer, auf denen sie laufen. Von daher macht ein TI DSP noch keinen guten Synthesizer - verhindern tut er ihn aber auch nicht
Moogulator
Admin
na, nen prozessor gabs in vielen synths, zb motorola 68er in
na, nen prozessor gabs in vielen synths, zb motorola 68er in den http://www.sequencer.de/syns/waldorf Waldorf synths und so..
chiplisten: http://sequencer.de/synth/index.php/Chips_in_Synthesizers Curtis,SSM,DSP Chips
na, nen prozessor gabs in vielen synths, zb motorola 68er in den http://www.sequencer.de/syns/waldorf Waldorf synths und so..
chiplisten: http://sequencer.de/synth/index.php/Chips_in_Synthesizers Curtis,SSM,DSP Chips
[quote:642563683d=*Moogulator*]na, nen prozessor gabs in vie
Ich wollte damit ja nicht sagen, dass es im Speckie keinen "prozessor" gibt. Nur meist fragen die Leute eher nach dem DSP und nicht nach dem Prozessor, weil letzterer meist noch austauschbarer ist, als der DSP, der schon mal wenigstens generell für Audio Anwendungen geeignet sein sollte. Als Microcontroller (Prozessor) haben wir einen Renesas M16C Controller im Spectralis.
Moogulator schrieb:
Ich wollte damit ja nicht sagen, dass es im Speckie keinen "prozessor" gibt. Nur meist fragen die Leute eher nach dem DSP und nicht nach dem Prozessor, weil letzterer meist noch austauschbarer ist, als der DSP, der schon mal wenigstens generell für Audio Anwendungen geeignet sein sollte. Als Microcontroller (Prozessor) haben wir einen Renesas M16C Controller im Spectralis.
Moogulator
Admin
thx, das wolltenwerwissen..
und schon auf der chipliste
thx, das wolltenwerwissen..
und schon auf der chipliste
und schon auf der chipliste
thx, das wolltenwerwissen..
und schon auf der chipliste
A
Anonymous
Guest
[quote:722f92e8d1=*Moogulator*]thx, das wolltenwerwissen.. ;
mal ne "dumme frage" dazu.
wo bekommt man die spezifikationen für die DSP wahl denn her ? durchforstet man da alle hersteller und die designs oder wie stelle ich mir das vor ? weil man benötigt doch dazu so nen chip auf ne PCI-karte o.ä.
oder liege ich da jetzt gänzlich falsch ?
thx
Moogulator schrieb:thx, das wolltenwerwissen..
und schon auf der chipliste
mal ne "dumme frage" dazu.
wo bekommt man die spezifikationen für die DSP wahl denn her ? durchforstet man da alle hersteller und die designs oder wie stelle ich mir das vor ? weil man benötigt doch dazu so nen chip auf ne PCI-karte o.ä.
oder liege ich da jetzt gänzlich falsch ?
thx
[quote:9d525b925d=*chain*][quote:9d525b925d=*Moogulator*]thx
Man studiert Datenblätter, überschaut die Kosten für etwaigere Entwicklungstools und baut mit Hilfe der Datenblätter eine hübsche Platine. Ich glaube die wichtigste Arbeit findet Jahre vorher statt - die Aneignung von nötigem KnowHow um bei dieser Materie halbwegs durchzublicken
chain schrieb:Moogulator schrieb:thx, das wolltenwerwissen..
und schon auf der chipliste
mal ne "dumme frage" dazu.
wo bekommt man die spezifikationen für die DSP wahl denn her ? durchforstet man da alle hersteller und die designs oder wie stelle ich mir das vor ? weil man benötigt doch dazu so nen chip auf ne PCI-karte o.ä.
oder liege ich da jetzt gänzlich falsch ?
thx
Man studiert Datenblätter, überschaut die Kosten für etwaigere Entwicklungstools und baut mit Hilfe der Datenblätter eine hübsche Platine. Ich glaube die wichtigste Arbeit findet Jahre vorher statt - die Aneignung von nötigem KnowHow um bei dieser Materie halbwegs durchzublicken
A
Anonymous
Guest
[quote:db01b7560d=*Elektro_Lurch*]
Man studiert Datenbl
wie, man muß ne eigene entwicklerplatine bauen ?
was ist ein enticklungstool (softwareumgebung oder wie ?)
stell mir das halt so ein wenig so, wie ne UAD1 karte vor und man programmiert eben um den chip den code
ist das assempler oder was eigentlich für ne sprache ? c++ wird es doch wohl nicht sein
thx
Man studiert Datenbl
Elektro_Lurch schrieb:Man studiert Datenblätter, überschaut die Kosten für etwaigere Entwicklungstools und baut mit Hilfe der Datenblätter eine hübsche Platine. Ich glaube die wichtigste Arbeit findet Jahre vorher statt - die Aneignung von nötigem KnowHow um bei dieser Materie halbwegs durchzublicken
wie, man muß ne eigene entwicklerplatine bauen ?
was ist ein enticklungstool (softwareumgebung oder wie ?)
stell mir das halt so ein wenig so, wie ne UAD1 karte vor und man programmiert eben um den chip den code
ist das assempler oder was eigentlich für ne sprache ? c++ wird es doch wohl nicht sein
thx
[quote:7a32ce316c=*chain*][quote:7a32ce316c=*Elektro_Lurch*]
Natürlich gibt es auch fertige Entwicklungsboards von der Stange zu kaufen - mit einem konkreten Ziel vor Augen benötigt man aber natürlich sein eigentliches Target für die Entwicklung - also eine Speckie Prototyp Platine. Das meinte ich mit Entwicklerplatine.
Im Laufe der Zeit haben wir für die Spectralis Entwicklung drei verschiedene Hardware-Ansätze entwickelt, die jedesmal performanter und tauglicher wurden.
Programmiert wird schon in C - timingkritische Sachen werden aber per Assembler optimiert. Im Grunde schaut man sich an, was der TI Compiler für einen Code produziert. Der optimiert so manche C-Routinen schon recht ordentlich - durch Optimierung bekommt man trotzdem oft noch deutlichst bessere Ergebnisse hin. Der TI kann mehrere Floating Point Multiplikationen pro Taktzyklus berechnen. Manchmal ist man regelrecht erstaunt, wie gut der C-Code kompiliert wird - bei anderen Routinen erzeugt das Ergebnis Frust. Man beginnt dann den C-Code so zu schreiben, dass der Compiler möglichst gut optimieren kann. Mit der Zeit hat man da ein paar Kniffe raus.
Trotzdem führt an Assember und sehr guten Mathekenntnissen kein Weg vorbei, wenn man etwas vernünftiges aus einem DSP herauskitzeln will. Ich bin da leider relativ unbedarft. Aber zum Glück haben wir ja den Andreas....
Hier trotzdem nochmal der Link zu dem Drumgroove. Der ist ja mittlerweile schon wieder gut versteckt.
und hier auch richtiger Scheissdreck:
chain schrieb:Elektro_Lurch schrieb:Man studiert Datenblätter, überschaut die Kosten für etwaigere Entwicklungstools und baut mit Hilfe der Datenblätter eine hübsche Platine. Ich glaube die wichtigste Arbeit findet Jahre vorher statt - die Aneignung von nötigem KnowHow um bei dieser Materie halbwegs durchzublicken
wie, man muß ne eigene entwicklerplatine bauen ?
was ist ein enticklungstool (softwareumgebung oder wie ?)
stell mir das halt so ein wenig so, wie ne UAD1 karte vor und man programmiert eben um den chip den code
ist das assempler oder was eigentlich für ne sprache ? c++ wird es doch wohl nicht sein
thx
Natürlich gibt es auch fertige Entwicklungsboards von der Stange zu kaufen - mit einem konkreten Ziel vor Augen benötigt man aber natürlich sein eigentliches Target für die Entwicklung - also eine Speckie Prototyp Platine. Das meinte ich mit Entwicklerplatine.
Im Laufe der Zeit haben wir für die Spectralis Entwicklung drei verschiedene Hardware-Ansätze entwickelt, die jedesmal performanter und tauglicher wurden.
Programmiert wird schon in C - timingkritische Sachen werden aber per Assembler optimiert. Im Grunde schaut man sich an, was der TI Compiler für einen Code produziert. Der optimiert so manche C-Routinen schon recht ordentlich - durch Optimierung bekommt man trotzdem oft noch deutlichst bessere Ergebnisse hin. Der TI kann mehrere Floating Point Multiplikationen pro Taktzyklus berechnen. Manchmal ist man regelrecht erstaunt, wie gut der C-Code kompiliert wird - bei anderen Routinen erzeugt das Ergebnis Frust. Man beginnt dann den C-Code so zu schreiben, dass der Compiler möglichst gut optimieren kann. Mit der Zeit hat man da ein paar Kniffe raus.
Trotzdem führt an Assember und sehr guten Mathekenntnissen kein Weg vorbei, wenn man etwas vernünftiges aus einem DSP herauskitzeln will. Ich bin da leider relativ unbedarft. Aber zum Glück haben wir ja den Andreas....
Hier trotzdem nochmal der Link zu dem Drumgroove. Der ist ja mittlerweile schon wieder gut versteckt.
und hier auch richtiger Scheissdreck:
W
wqretrhtfsdrtz
Guest
[quote:25e0ee4996=*Elektro_Lurch*][quote:25e0ee4996=*Moogula
Naja, Dir brauche ich es ja eigentlich nicht zu sagen: Der DSP ist ein Prozessor. Ich formulierte die Frage lieber allgemein, schließlich war der Einsatz von FPGAs im Vorfeld nicht auszuschließen und der Einsatz eines general purpose Controllers wahrscheinlich. Und die Nachfrage ergab schließlich, daß neben den TI DSPs auch noch Renesas Controller eingesetzt wurden (von denen ich nie zuvor gehört habe).
Elektro_Lurch schrieb:
Naja, Dir brauche ich es ja eigentlich nicht zu sagen: Der DSP ist ein Prozessor. Ich formulierte die Frage lieber allgemein, schließlich war der Einsatz von FPGAs im Vorfeld nicht auszuschließen und der Einsatz eines general purpose Controllers wahrscheinlich. Und die Nachfrage ergab schließlich, daß neben den TI DSPs auch noch Renesas Controller eingesetzt wurden (von denen ich nie zuvor gehört habe).
W
wqretrhtfsdrtz
Guest
[quote:cf4bd73693=*Elektro_Lurch*]
Programmiert wird schon
Programmiertechnisch schätzte ich das auch so ein. Unser Programmier-Prof meint, im E-Technik Studium bräuchte man keinen Assembler "weil es bis zum Ergebnis viel zu lange dauert". Stattdessen arbeiten wir mit dem Microsoft C-Compiler
. Ich lachte den Mentor daraufhin aus. Der hat ja auch irgendwas nicht mitgekriegt. Jedenfalls war sein einziges Gegenargument "das sehe ich nicht so" 
Programmiert wird schon
Elektro_Lurch schrieb:
Programmiertechnisch schätzte ich das auch so ein. Unser Programmier-Prof meint, im E-Technik Studium bräuchte man keinen Assembler "weil es bis zum Ergebnis viel zu lange dauert". Stattdessen arbeiten wir mit dem Microsoft C-Compiler
. Ich lachte den Mentor daraufhin aus. Der hat ja auch irgendwas nicht mitgekriegt. Jedenfalls war sein einziges Gegenargument "das sehe ich nicht so"
A
Anonymous
Guest
[quote:759bdaed36=*Alisa 1387*]
Programmiertechnisch sch
gerade beim Techniker Informatik
hacken ein paar dozenten "nur" assembler rum
und andere wieder auf C
ich denke "gut wenn man beides kann"
was nun das wichtigere ist ?
es gibt die meinung das in sachen assembler, heute eh meist vorgefertigten "bausätzen" angeboten werden (z.b. für SPS programmierung)
ich denke "immer gut, wenn man sein handwerk von der picke auf kann"
nur wo sind da die prioritäten zu setzten ?
Programmiertechnisch sch
Alisa 1387 schrieb:Programmiertechnisch schätzte ich das auch so ein. Unser Programmier-Prof meint, im E-Technik Studium bräuchte man keinen Assembler "weil es bis zum Ergebnis viel zu lange dauert". Stattdessen arbeiten wir mit dem Microsoft C-Compiler
gerade beim Techniker Informatik
hacken ein paar dozenten "nur" assembler rum
und andere wieder auf C
ich denke "gut wenn man beides kann"
was nun das wichtigere ist ?
es gibt die meinung das in sachen assembler, heute eh meist vorgefertigten "bausätzen" angeboten werden (z.b. für SPS programmierung)
ich denke "immer gut, wenn man sein handwerk von der picke auf kann"
nur wo sind da die prioritäten zu setzten ?
A
Anonymous
Guest
Eindeutig auf 'erstmal Programmieren lernen'. Und das kann m
Eindeutig auf 'erstmal Programmieren lernen'. Und das kann man in Assembler eher schlecht und in C++ besser als in C.
Normalerweise schreibt man den Code ja sowieso erstmal in C (...), optimiert dann den Algorithmus - und zwar nur an den signifikanten Stellen - und wenn es dann immer noch nicht reicht, dann kann man vielleicht zum Assembler greifen, am besten wirklich nur um - wie beschrieben- den Compiler so zu treten das er brauchbares Zeugs erzeugt.
Mit von der 'Pike auf Lernen' hat Assembler nix zu tun, die meisten Leute die mit Assembler anfangen, schreiben hinterher ziemlich grottige Programme.
Je moderner die CPU desto unsinniger wird Assembler, vor allem bei Desktop-CPUs ist Assembler praktisch sinnlos. (Der optimierte Code wartet dann länger auf den Speicher.)
Es ist wirklich auffällig wie viele Leute, grade auch Anfänger, die wildesten Verrenkungen machen um Code vermeintlich zu optimieren. In den ersten (sagen wir mal 5) Jahren des programmieren-lernens sollte die einzige Optimierung die auf lesbaren, wartbaren und verständlichen Code sein.
Eindeutig auf 'erstmal Programmieren lernen'. Und das kann man in Assembler eher schlecht und in C++ besser als in C.
Normalerweise schreibt man den Code ja sowieso erstmal in C (...), optimiert dann den Algorithmus - und zwar nur an den signifikanten Stellen - und wenn es dann immer noch nicht reicht, dann kann man vielleicht zum Assembler greifen, am besten wirklich nur um - wie beschrieben- den Compiler so zu treten das er brauchbares Zeugs erzeugt.
Mit von der 'Pike auf Lernen' hat Assembler nix zu tun, die meisten Leute die mit Assembler anfangen, schreiben hinterher ziemlich grottige Programme.
Je moderner die CPU desto unsinniger wird Assembler, vor allem bei Desktop-CPUs ist Assembler praktisch sinnlos. (Der optimierte Code wartet dann länger auf den Speicher.)
Es ist wirklich auffällig wie viele Leute, grade auch Anfänger, die wildesten Verrenkungen machen um Code vermeintlich zu optimieren. In den ersten (sagen wir mal 5) Jahren des programmieren-lernens sollte die einzige Optimierung die auf lesbaren, wartbaren und verständlichen Code sein.
A
Anonymous
Guest
[quote:0521e03c1d=*Fetz*]Eindeutig auf 'erstmal Programmiere
analog ner echten sprache eben
ja und weil ich das mit dem assembler mir auch auch so denke, ist diese schule von mir auch abgewählt worden 8)
und mal schauen wie das in der anderen läuft
Fetz schrieb:
analog ner echten sprache eben
ja und weil ich das mit dem assembler mir auch auch so denke, ist diese schule von mir auch abgewählt worden 8)
und mal schauen wie das in der anderen läuft
Kaneda
..
Ich bin der Meinung das jeder, der Software egal f
Ich bin der Meinung das jeder, der Software egal für welche Anwendung entwickelt, zumindest grundlegend Ahnung von Assembler haben sollte (egal für welche Plattform).
Das heisst nicht das auch alles in Maschienensprache geschrieben werden muss, im Gegenteil, aber ich kenne zuviele Entwickler welche ohne gewisse Grundkenntnisse in den Abläufen einer CPU bzw. eines Rechners ihren Job machen und hab meine Meinung dazu.
Spätestens wenn Ihr Code ihnen um die Ohren fliegt wegen Stack Überlaufs, Zugriff auf nicht reservierte Speicherbereiche, was auch immer, gehts dann mit dem Voodoo-Zauber los. Da wird dann solange am Code rumgeschraubt "bis es irgendwie geht". Oder Komplette Entwicklungsrechner werden neu installiert "weil es vielleicht daran liegt". Die Qualität der Software ist dann dementsprechend. Andere würden dann hier vielleicht einen Debugger zu Rate ziehen und sich dann eben auf die Maschienenebene begeben und den Code durchgehen.
Hab vor Jahren mal erlebt wie ein Entwickler mir verkaufen wollte, das es prinzipiell eine gute Eigenschaft eines Programmierers sei, nichts von Registern etc. zu verstehen. Aha. So als wenn mein Kfz-Mechaniker sagen würde : "wie ein Verbrennungsmotor funktioniert weiß ich nicht, aber das macht mich zu einem guten Mechaniker".
So sehe ich das.
Ich bin der Meinung das jeder, der Software egal für welche Anwendung entwickelt, zumindest grundlegend Ahnung von Assembler haben sollte (egal für welche Plattform).
Das heisst nicht das auch alles in Maschienensprache geschrieben werden muss, im Gegenteil, aber ich kenne zuviele Entwickler welche ohne gewisse Grundkenntnisse in den Abläufen einer CPU bzw. eines Rechners ihren Job machen und hab meine Meinung dazu.
Spätestens wenn Ihr Code ihnen um die Ohren fliegt wegen Stack Überlaufs, Zugriff auf nicht reservierte Speicherbereiche, was auch immer, gehts dann mit dem Voodoo-Zauber los. Da wird dann solange am Code rumgeschraubt "bis es irgendwie geht". Oder Komplette Entwicklungsrechner werden neu installiert "weil es vielleicht daran liegt". Die Qualität der Software ist dann dementsprechend. Andere würden dann hier vielleicht einen Debugger zu Rate ziehen und sich dann eben auf die Maschienenebene begeben und den Code durchgehen.
Hab vor Jahren mal erlebt wie ein Entwickler mir verkaufen wollte, das es prinzipiell eine gute Eigenschaft eines Programmierers sei, nichts von Registern etc. zu verstehen. Aha. So als wenn mein Kfz-Mechaniker sagen würde : "wie ein Verbrennungsmotor funktioniert weiß ich nicht, aber das macht mich zu einem guten Mechaniker".
So sehe ich das.
Moogulator
Admin
wer HArdwarenah was macht, sollte das k
wer HArdwarenah was macht, sollte das können.. damals war das wegen Tempo und heute kann sowas schon helfen..
wer Hard-Bastel machen will, sollte sich nicht nur auf C verlassen
wer HArdwarenah was macht, sollte das können.. damals war das wegen Tempo und heute kann sowas schon helfen..
wer Hard-Bastel machen will, sollte sich nicht nur auf C verlassen
C0r€
|||||
so ca. 10 mal schneller ist auch heutzutage mit assemler noc
so ca. 10 mal schneller ist auch heutzutage mit assemler noch drin.
Kommt ein wenig auf den compiler der Hochsprache drauf an, aber meistens kann man noch unzählige push und pop noch rausfeuern und dergelichen. Das macht sich besonders bei schleifen bezahlt.
Ganz schlimm, wenn man in schleifen dann funktionen aufruft die wieder funktionen aufrufen usw. dann gibts zwar nette schlüsselwörter ala inline und -o sonstewas, aber da geht manchemal auch mehr kaputt als das es schneller wird.
ist wie tieferlegen eines autos, manche straßen kann man dann einfach nichtmehr langfahren.
Problematisch ist aber eben immer die Kompatibilitätsfrage...
so ca. 10 mal schneller ist auch heutzutage mit assemler noch drin.
Kommt ein wenig auf den compiler der Hochsprache drauf an, aber meistens kann man noch unzählige push und pop noch rausfeuern und dergelichen. Das macht sich besonders bei schleifen bezahlt.
Ganz schlimm, wenn man in schleifen dann funktionen aufruft die wieder funktionen aufrufen usw. dann gibts zwar nette schlüsselwörter ala inline und -o sonstewas, aber da geht manchemal auch mehr kaputt als das es schneller wird.
ist wie tieferlegen eines autos, manche straßen kann man dann einfach nichtmehr langfahren.
Problematisch ist aber eben immer die Kompatibilitätsfrage...
A
Anonymous
Guest
Grad beim hardwarenahen Kram versuche ich mir das mit dem As
Grad beim hardwarenahen Kram versuche ich mir das mit dem Assembler abzugewöhnen. Geschwindigkeit und Grösse spielen dabei oft keinen Rolle (ob ich den Chip nach dem Booten nun in 250 oder 175µs initialisiert habe...) und wehe man muß das mal portieren.
Erstmal alles in C und dann gucken wo es klemmt.
Das einzige was in C wirklich nicht geht ist die Prozeßumschaltung fürs Multitastking - das sind aber nur ein paar zehn Befehle und ein paar Funktionen drumrum die 'unteilbar' sein müssen. (Für Semaphore und son Zeugs.)
Ob grundlegende Ahnung reicht: 'Der Code läuft nicht mehr wenn ich das printf(); rausmache, blöder Compiler'. Und der Typ konnte Assembler...
wie zu erwarten wars natürlich ein etwas knapp dimensinierter String auf dem Stack.
Bei Hardware-Basteleien ist das schon was anderes: erstens sind hier oft 8 Bitter am Werk - denen bekommt der Compileroutput nicht wirklich gut. Eventuell ist das Projekt/Buget relativ klein und so eine Entwicklungsumgebung für C ist nicht eben billig.
10 mal schneller hab ich im Einzelfall beim 68360 noch geschafft (Embedded Mischmasch-kern zwischen 68000 und 68020), beim Coldfire ist vielleicht noch mal Faktor 2 drin, manchmal auch nix. (Der ist sehr undankbar weil er kein Virtual Memory hat und daher Schreibzugriffe komplett wegpuffert. Viele Schleifen, die schreiben hängen dadurch an der Memory-Schreibrate fest.)
Der Metrowerks Compiler macht beim Optimieren lustige Sachen: in einer mittleren Stufe erzeugt er mehr Code weil er unbedingt Register verwenden will, der Unsinn wird aber erst in der nächsthöheren Stufe wieder rausgeworfen. Der höchstoptimierte Code ist erstaunlicherweise am lesbarsten, und bei nicht-tivialen Sachen per Hand nicht sooo viel besser zu bekommen. Kurze Schleifen sind oft gruselig, das ist aber egal, da der Code dort praktisch keine Zeit kostet sondern nur die Datenzugriffe. Ausser beim Microsoft-Compiler kenne ich destruktive Optimierungen nur bei Code-Fehlern. (vergessene oder falsche Volatile...)
Grad beim hardwarenahen Kram versuche ich mir das mit dem Assembler abzugewöhnen. Geschwindigkeit und Grösse spielen dabei oft keinen Rolle (ob ich den Chip nach dem Booten nun in 250 oder 175µs initialisiert habe...) und wehe man muß das mal portieren.
Erstmal alles in C und dann gucken wo es klemmt.
Das einzige was in C wirklich nicht geht ist die Prozeßumschaltung fürs Multitastking - das sind aber nur ein paar zehn Befehle und ein paar Funktionen drumrum die 'unteilbar' sein müssen. (Für Semaphore und son Zeugs.)
Ob grundlegende Ahnung reicht: 'Der Code läuft nicht mehr wenn ich das printf(); rausmache, blöder Compiler'. Und der Typ konnte Assembler...
wie zu erwarten wars natürlich ein etwas knapp dimensinierter String auf dem Stack.
Bei Hardware-Basteleien ist das schon was anderes: erstens sind hier oft 8 Bitter am Werk - denen bekommt der Compileroutput nicht wirklich gut. Eventuell ist das Projekt/Buget relativ klein und so eine Entwicklungsumgebung für C ist nicht eben billig.
10 mal schneller hab ich im Einzelfall beim 68360 noch geschafft (Embedded Mischmasch-kern zwischen 68000 und 68020), beim Coldfire ist vielleicht noch mal Faktor 2 drin, manchmal auch nix. (Der ist sehr undankbar weil er kein Virtual Memory hat und daher Schreibzugriffe komplett wegpuffert. Viele Schleifen, die schreiben hängen dadurch an der Memory-Schreibrate fest.)
Der Metrowerks Compiler macht beim Optimieren lustige Sachen: in einer mittleren Stufe erzeugt er mehr Code weil er unbedingt Register verwenden will, der Unsinn wird aber erst in der nächsthöheren Stufe wieder rausgeworfen. Der höchstoptimierte Code ist erstaunlicherweise am lesbarsten, und bei nicht-tivialen Sachen per Hand nicht sooo viel besser zu bekommen. Kurze Schleifen sind oft gruselig, das ist aber egal, da der Code dort praktisch keine Zeit kostet sondern nur die Datenzugriffe. Ausser beim Microsoft-Compiler kenne ich destruktive Optimierungen nur bei Code-Fehlern. (vergessene oder falsche Volatile...)
lfo-one
||
hallo bevor der trade ausstirbt hab ich mir gedacht ich geb
hallo bevor der trade ausstirbt hab ich mir gedacht ich geb euch mal ein bischen soundfutter!!! für die die den spectralis noch nicht besitzen!!!
auf meiner website habe ich eine kleine spectralisseite eingerichtet die natürlich noch mit informationen und weiteren sounds aktualisiert werden soll
http://www.lfo-one.de
grüsse der speckiman!!!
hallo bevor der trade ausstirbt hab ich mir gedacht ich geb euch mal ein bischen soundfutter!!! für die die den spectralis noch nicht besitzen!!!
auf meiner website habe ich eine kleine spectralisseite eingerichtet die natürlich noch mit informationen und weiteren sounds aktualisiert werden soll
http://www.lfo-one.de
grüsse der speckiman!!!
Similar threads
- Strix
- SyntheTisch
News
-
News SequencerTalk 233 PolyEnd Synth, Fors Dyad, Dreadbox Artemis, Updates, Mac, GliGli Synth- Gestartet von Moogulator
- Antworten: 0
-
News Drums, Steuerung, away from keyboard - afk drumbeam - Talk und Synthnews im SequencerTalk 222
- Gestartet von Moogulator
- Antworten: 1
-
Ankündigung: "SynMag Sonderausgabe 02: Inspiration" erscheint am 21.11.- Gestartet von Björn
- Antworten: 0
-
News Wie multi poly bist du? SequencerTalk 221 heute um 20:30 live
- Gestartet von Moogulator
- Antworten: 1
-
Apple Updatewoche iMac, MacBook Pro und kleinerer Mac Mini mit M4 (bis Max) - Leistungsvergleich DAWs und Musik welche ist am besten?
- Gestartet von Moogulator
- Antworten: 105
-
-