Hallo FOrum, hat schonmal jmd einen packungsalgorhitmus in ASM geschrieben und könnte den hier posten?
Guest_uc schrieb: > Hallo FOrum, > > hat schonmal jmd einen packungsalgorhitmus in ASM geschrieben und könnte > den hier posten? Was sind die genauen Anforderungen. Sprich welche Daten müsstest du packen. Das Problem: ausgefuchste Pack-Algorithmen sind leider auch meistens recht umfangreich und benötigen zwischendurch viel Speicher. D.h. eventuell wirst du da abspecken müssen. Das hängt wiederrum nicht unwesentlich davon ab, welche Daten du packen musst, wie variabel die sind und was du dir davon erhoffst. Wichtig wäre auch zu wissen, auf welchem Prozessor das ganze laufen soll. Auf einem Mega128 hat man mehr Spielraum als auf einem kleinen Tiny.
Karl H. schrieb im Beitrag #4291888: > Also sei nicht so. Schüttel eine Huffmann Kompression aus dem Ärmel, das > es nur so staubt. Kann ja nicht so schwer sein. Ist doch praktisch > selbsterklärend. Der Herr heißt David A. Huffman, mit einem "n".
sprotte24 schrieb: > Karl H. schrieb im Beitrag #4291888: >> Also sei nicht so. Schüttel eine Huffmann Kompression aus dem Ärmel, das >> es nur so staubt. Kann ja nicht so schwer sein. Ist doch praktisch >> selbsterklärend. > > Der Herr heißt David A. Huffman, mit einem "n". Merci vielmals.
Um wieder ontopic zu kommen: Ich wuerde mir gut ueberlegen, ob ich das in asm tun moechte ... du wirst eher fuer generisches c speicheroptimierte algorithmen finden, als fuer das asm eines atmegas.
Guest_uc schrieb: > Hallo FOrum, > > hat schonmal jmd einen packungsalgorhitmus in ASM geschrieben und könnte > den hier posten? Hallo Guest_uc, hast Du schonmal einen sinnvollen Anwendungsfall hierfür definiert und könntest den hier posten?
:
Bearbeitet durch User
EinGast schrieb: > Um wieder ontopic zu kommen: Ich wuerde mir gut ueberlegen, ob ich das > in asm tun moechte ... du wirst eher fuer generisches c > speicheroptimierte algorithmen finden, als fuer das asm eines atmegas. Die Sprache ist bei diesem Problem mal überhaupt nicht das Problem, sondern einzig die fehlende RAM-Kapazität der allermeisten AVR8 und auch aller vergleichbaren µC derselben Klasse. Es ist nunmal unmöglich, den optimalen Baum auch im worst case zu bauen, wenn der Speicher schon nichtmal für diesen blöden Baum selber reicht, geschweige denn, um parallel dazu auch noch wenigstens das aktuelle Input-Paket vollständig aufzunehmen. UND: Wer das nicht selber erkennen kann, ist definitiv C-Programmierer (oder eigentlich eher: C&P-"Programmierer", also: struktureller Vollidiot, weil er den Algorithmus garnicht begreift, sondern nur Leichen fleddert) Der einzige Ausweg aus der generellen RAM-Misere kleiner µC ist natürlich die Veringerung der Bitbreite der Datenwörter für den Algorithmus. Das erzwingt i.d.R. allerdings überproportional längliche Verarbeitungszeiten und recht lausige Kompressionsergebnisse. Aber immerhin: Mit Assembler kann man hier wenigstens bezüglich der Verarbeitungszeiten sehr gut punkten. Mit Teilen von "char" kann C nämlich nicht gerade sehr effizient umgehen. Allerdings: auch der Assembler-Vorteil macht die Sache insgesamt höchstens dann sinnvoll brauchbar, wenn die zu packenden Daten irgendwie "günstig" bezüglich des Packens strukturiert sind, was leider nur recht selten der Fall ist. Einziges Gegenbeispiel, was mir dazu auf Anhieb einfällt: Text. Hier kann man mittels Huffman-Encoding mit 4Bit-Datenwörtern tatsächlich nochmal erheblich Speicher sparen. Und sowohl Encoder als auch Decoder dafür sind selbst auf sehr kleinen AVR8 (sinnvoll so etwa ab Tiny13) zumindest einigermaßen effizient in Asm realisierbar. Wobei hier berücksichtigt ist, das zumindest der Mehrverbrauch an Flash durch den Entpacker nennenswert geringer sein sollte als der erzielte Gewinn beim Packgut. Das ist selbst bei den ganz kleinen AVR8 mit nur 1kB Flash relativ leicht zu erreichen, wenn deren Flash zu etwa einem Drittel oder mehr mit Stringkonstanten vollgemüllt ist.
Für moderne Kompressionsalgorithmen sind die AVRs nicht wirklich die erste Wahl. Ich kann mir nicht vorstellen Piedpiper und Konsorten auf einem Tiny10 zu implementieren. Da fehlt schon der Speicher. Was aber tatsächlich Sinn machen kann, ist eine RLE oder Deltakompression. Ich kann Dir leider keinen fertigen Code anbieten, aber die Links sollten helfen: https://de.wikipedia.org/wiki/Laufl%C3%A4ngenkodierung https://en.wikipedia.org/wiki/Delta_encoding Bei den richtigen Daten kann das den mittleren(!) Durchsatz über eine langsame serielle Schnittstelle gewaltig erhöhen.
c-hater schrieb: > Die Sprache ist bei diesem Problem mal überhaupt nicht das Problem, > sondern einzig die fehlende RAM-Kapazität der allermeisten AVR8 und auch > aller vergleichbaren µC derselben Klasse. Marcus H. schrieb: > Für moderne Kompressionsalgorithmen sind die AVRs nicht wirklich die > erste Wahl. Ach Leute. Das Problem ist nicht der Mangel an Kompressionsalgorithmen (respektive Implementierungen) sondern daß man im Gegenteil damit zugeschmissen wird. Und zwar insbesondere auch mit Varianten die besonders geringen Resourcenverbrauch beim Entpacken haben. Eine konkrete Empfehlung kann man aber nicht aussprechen ohne etwas über die zu (ent)packenden Daten zu wissen. Womöglich reicht ja schon RLE als Kompressionsverfahren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.