Assembler-Testumgebung für totale Anfänger

*john 0

@zeropage sagte in Assembler-Testumgebung für totale Anfänger:

Es gibt ja noch die ganz alten Minicomputer. Die 8bit aus den 80zigern. Da gab es ja so gut wie keine Möglichkeit außer Assembler.

Das sind Microcomputer, die Minicomputer waren meistens schon 16Bit Systeme z.B. PDP-11 oder VAX-11.

hustbaer

@Quiche-Lorraine
Ich denke es ist in vielen Situationen sinnvoll Assembler zu können. Zumindest so gut dass man Disassembly mehr oder weniger flüssig lesen kann. Es ist nützlich wenn man...

Code optimieren möchte
Crashes debuggen möchte
Generell besser verstehen möchte wie eine CPU wirklich arbeitet

Wobei es natürlich am meisten Sinn macht die Assembler-Variante für die CPU zu können mit der man dann hauptsächlich arbeitet.

Quiche Lorraine

@hustbaer sagte in Assembler-Testumgebung für totale Anfänger:

Ich denke es ist in vielen Situationen sinnvoll Assembler zu können. Zumindest so gut dass man Disassembly mehr oder weniger flüssig lesen kann. Es ist nützlich wenn man...

Code optimieren möchte
Crashes debuggen möchte
Generell besser verstehen möchte wie eine CPU wirklich arbeitet

Wobei es natürlich am meisten Sinn macht die Assembler-Variante für die CPU zu können mit der man dann hauptsächlich arbeitet.

Sehe ich ein wenig anders. Klar ist es sinnvoll Assembly zu lernen damit man die CPU besser versteht und man Disassembly lesen kann.

Aber warum benötige ich beispielsweise beim Debugging Assembly wo es doch viele andere Debugging Techniken gibt?

Ich folgenden beziehe ich mich auf Mikrocontroller ala STM.

Modernere Mikrocontroller IDEs / Debugger Hardware erlauben inzwischen auch Debugging wie in Visual Studio, wo man also durch den Sourcecode steppen kann.

Ferner gibt es dann noch das unrühmliche printf/Uart Debugging, welche den internen Zustand liefert. Nicht wenige Probleme habe ich durch Logging von Controller Messdaten und Darstellung in Excel entdeckt.

Und wenn man hochperiodisches Verhalten untersuchen möchte, nutzt man einen Pin, setzt den Pin auf High wenn Funktion startet, setzt den Pin auf Low wenn die Funktion beendet. Und dann schaut man sich den Pin mit einem Oszi an.

Und zuguterletzt habe ich noch die Simulation schätzen gelernt. Also versuchen den Code soweit wie möglich auf den PC zu übertragen, damit man diesen dort testen/debuggen kann.

Mechanics

@Quiche-Lorraine sagte in Assembler-Testumgebung für totale Anfänger:

Aber warum benötige ich beispielsweise beim Debugging Assembly wo es doch viele andere Debugging Techniken gibt?

Oh, das braucht man durchaus oft. Man kriegt öfter mal core dumps von Kunden, die teilweise gar nicht mehr so einfach zu rekonstruieren sind, da kommt man ohne Assemblerkenntnisse teilweise gar nicht mehr weiter.
Und auch beim Livedebuggen gibt es immer wieder schwierige Situationen, die man ohne Assemblerkenntnisse nicht versteht.
Zumal zumindest der MSVC Compiler mittlerweile immer öfter fehlerhaften Code produziert. Vor 5-10 Jahren war es noch extrem unwahrscheinlich, über einen Compilerbug zu stolpern. Mittlerweile müssen wir alle 3-6 Monate feststellen, dass der Compiler Mist gebaut hat.

hustbaer

@Quiche-Lorraine sagte in Assembler-Testumgebung für totale Anfänger:

Aber warum benötige ich beispielsweise beim Debugging Assembly wo es doch viele andere Debugging Techniken gibt?

Ich meinte eher Debuggen von Crash-Dumps. Sobald du was reproduzierbares hast was du mit Code-Änderungen testen kannst, hast du in 90% der Fälle sowieso schon gewonnen. Wenn du aber nur nen Core Dump bekommst, und erstmal keine Ahnung hast wie du den Fehler reproduzieren kannst, ... dann sind Assembler-Kenntnisse schon oft hilfreich.

Leon0402

In der Uni verwenden wir einen Dosbox als Emulator, um Assembler zu lernen. Der Befehlssatz ist dadurch überschaubar. Dazu einfach nen Assembler Debbuger und Compiler und los gehts.

Kann nicht beurteilen, ob das die sinnvollste oder beste Art ist. Aber für mich bzw. das Uni Modul erfüllt es seinen Zweck.

Quiche Lorraine

@hustbaer sagte in Assembler-Testumgebung für totale Anfänger:

Ich meinte eher Debuggen von Crash-Dumps. Sobald du was reproduzierbares hast was du mit Code-Änderungen testen kannst, hast du in 90% der Fälle sowieso schon gewonnen. Wenn du aber nur nen Core Dump bekommst, und erstmal keine Ahnung hast wie du den Fehler reproduzieren kannst, ... dann sind Assembler-Kenntnisse schon oft hilfreich.

Ok, das verstehe ich.

Ich hatte bisher Glück. Nur in wenigen Fällen musste ich in das Assembly schauen. Einmal nutzte ich eine doppelte Struct Definition, ohne dass der Compiler sich beschwerte. Dadurch kam es zu einem ganz üblen Seiteneffekt. Und einmal verweigerte ein Mikrokontroller den Schlafen-Legen-Befehl.

hustbaer

@Quiche-Lorraine Ja, ich brauch das jetzt auch nicht jeden Tag. Aber manchmal ist es wie gesagt hilfreich.

Was @Mechanics geschrieben hat ist uns auch schon öfter passiert - also dass wir über Compiler-Fehler gestolpert sind. Da ist es dann gut wenn man Assembler kann - auch wenn es meist nur dazu gut ist sicherzustellen dass es diesmal nicht ein Compiler-Fehler ist.

wob

Apropos Testumgebung: da ich endlich mal meinen Uralt-PC entsorgen will, habe ich zufällig beim Backup-Machen ein Programm zum Ausführen von "Assembler" gefunden, das ich in der Schule geschrieben habe (das Dateidatum war Mai 1999). Und zwar hat der Lehrer uns damals versucht Prolog beizugringen und wir haben dann in 1000+ Zeilen irgendeinen Assemblerinterpreter geschrieben (wir haben das "Registermaschine" genannt) und ich hatte am Ende keine Ahnung, warum der überhaupt funktionier hat.
Jedenfalls hatte ich das damals in Perl neu geschrieben, war kürzer, einfacher und schneller (allerdings habe ich damals offenbar keine Spaces um Operatoren gemocht, schüttel - aber abgesehen davon gut lesbar, obwohl Perl). Hier ist der Uralt-Code:

#!/usr/bin/perl -w

$#ARGV && die "Syntax: register.pl <file.asm>\n";

foreach (<>) {
  s/\s*(;.*)?$//;
  next if (/^$/);
  @geteilt=split(/ +/);
  $#geteilt==2 || die "Ungültige Zeile: $_\n";
  $befehl[$geteilt[0]]=$geteilt[1];
  $argument[$geteilt[0]]=$geteilt[2];
}

$befehlsZaehler=1;

while (1) {
  $bef=$befehl[$befehlsZaehler]; #fetch
  &$bef($argument[$befehlsZaehler++]); #execute
}

###########################################################################

sub ldk
{
  $akku=$_[0];
}

sub lda
{
  $akku=$daten[$_[0]];
}

sub sta
{
  $daten[$_[0]]=$akku;
}

sub add
{
  $akku+=$daten[$_[0]];
}

sub sub
{
  $akku-=$daten[$_[0]];
}

sub hlt
{
  exit(0);
}

sub inp
{
  print "Eingabe: ";
  $daten[$_[0]]=<STDIN>;
}

sub out
{
  print "Ausgabe: $daten[$_[0]]\n";
}

sub jmp
{
  $befehlsZaehler=$_[0];
}

sub jlz
{
  if ($akku<0) { $befehlsZaehler=$_[0]; }
}

sub jle
{
  if ($akku<=0) { $befehlsZaehler=$_[0]; }
}

sub jgz
{
  if ($akku>0) { $befehlsZaehler=$_[0]; }
}

sub jge
{
  if ($akku>=0) { $befehlsZaehler=$_[0]; }
}

sub jez
{
  unless ($akku) { $befehlsZaehler=$_[0]; }
}

sub jnz
{
  if ($akku) { $befehlsZaehler=$_[0]; }
}

und ein passendes Programm dazu (keine Ahnung mehr, was es tut, ich habe das damals nicht kommentiert, es hieß jedenfalls div.asm - es scheint div + mod zu machen...)

1 inp 1
2 inp 2
3 ldk 0
4 sta 3
5 lda 1
6 sub 2
7 jlz 15
8 lda 1
9 sub 2
10 sta 1
11 ldk 1
12 add 3
13 sta 3
14 jmp 5
15 out 3
16 out 1
17 hlt 99

Ich fands jedenfalls cool, dass wir sowas schon in der Schule gemacht haben.

@KlausDieter du kannst damit gerne rumspielen, neue Instruktionen erfinden und so weiter.

EinNutzer0

Hi @KlausDieter , schau Dir mal den RISC-V Venus Simulator embedded (https://marketplace.visualstudio.com/items?itemName=hm.riscv-venus) an (Erweiterung für VS Code), das ist bestimmt genau das, was Du suchst... (ich bin daran gescheitert, aber das muss ja nix heißen).

Edit: hoffe, wecke keine Leiche auf...

Erhard Henkes

https://www.henkessoft.de/Assembler/Assembler.htm
https://www.henkessoft.de/Roboter/stk500.htm