Ergebnis 1 bis 7 von 7

Thema: Assembler, Speicher und Netzwerk

  1. #1
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.876
    Renommee
    283

    Assembler, Speicher und Netzwerk

    Hallo,

    ich probiere gerade ein wenig in Assembler rum. Dazu habe ich u.a. folgende Quellen:



    Eine relativ einfache Einführung scheinbar. Habe bislang aber nur den ersten Link halb durchgearbeitet. Was ich aber weiß ist, dass eine Art "Kernel" zwar im MBR vorliegen
    kann, der kann aber bloß 512 Bytes lang sein. Was ich jetzt vermute ist, dass ich (z.B. von der Festplatte, adressierbar wohl per CHS(?)) einen "eigentlichen" Kernel laden
    sollte, an eine höhere, freie Speicheradresse, wo ich dann nur noch hinspringen müsste, wenn es sich um Bytecode handelt (`jmp`?) - ist das so weit richtig? Was ich dann
    weiter denke wären diverse Schutzmechanismen, wenn ich z.B. Speicheradressen als NON-Executable markierte oder auch eigenen Benutzer-IDs zuweisen würde, damit
    nur der eigentliche Besitzer auf diesen Speicher Zugriff erhält. Oder eine Art "LinkedList" diverser "randomized" Speicheradressen, die so virtuell zu einem großen Bereich
    würden? Ist das so weit korrekt gedacht?

    Mein nächstes Problem ist, dass ich zwar Festplatten-Zugriffe gefunden habe, aber bislang nichts über Ethernet bzw. NICs. Gibt es da auch BIOS-Routinen - oder wie kann
    ich mein kleines OS um Netzwerk-Zugriffe erweitern? Klar, alles sind im Prinzip Speicher-Mappings - kann man doch wohl so sagen - aber es müsste ein Hardware-Interrupt
    für NICs her?

    Dritte und letzte Frage: Segmentierung. Wohl dazu da, größere Speicherbereiche adressieren zu können, ohne die Bit-Breite erhöhen zu müssen. So ähnlich wie bei CHS!?
    Wenn ich aber später den 32- oder 64-Bit-Modus anschalte, wird Segmentierung dann überflüssig oder fahre ich gut, diese *immer* mit zu verwenden (weil's effizient ist oder
    so?).

    DANKE für eure Hilfe. Wer weitere gute Links hat, auch immer her damit. Der Kuchen.

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  2. #2
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.876
    Renommee
    283

    AW: Assembler, Speicher und Netzwerk

    Dritte und letzte Frage: Segmentierung. Wohl dazu da, größere Speicherbereiche adressieren zu können, ohne die Bit-Breite erhöhen zu müssen. So ähnlich wie bei CHS!?
    Wenn ich aber später den 32- oder 64-Bit-Modus anschalte, wird Segmentierung dann überflüssig oder fahre ich gut, diese *immer* mit zu verwenden (weil's effizient ist oder so?).
    So wie ich das jetzt (auf die schnelle) verstanden habe, gibt's im 32-Bit-Modus garnicht erst mehr die Segmentierung/Segmentation. Jfyi!

    Jetzt nur noch die Sache mit UEFI - bei dessen Verwendung wohl keine BIOS-Interrupts mehr zu verwenden sind. Blöde, weil ich bislang nur C-UEFI-Code gefunden habe, dabei möchte
    ich es doch unbedingt mit Assembler probieren. ...

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  3. #3
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.876
    Renommee
    283

    AW: Assembler, Speicher und Netzwerk

    Mein Problem ist jetzt, dass ich gerne aus dem eigenen Bootloader heraus (den habe ich schon etwas verstanden,
    habe auch schon Test-Systeme via `qemu` erfolgreich laden lassen) die "--fully-static"-kompilierte "node.js"-Executable
    als Kernel verwenden möchte.

    Problematisch scheint mir, dass "node.js" ein paar "/dev"-Geräte benötigt. ... wie könnte ich das hinkriegen, um dann
    einfach weiter in "High Level"-Scripting den Kernel usw. codieren zu können?

    Büdde büdde helft's mir. Thx.

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  4. #4
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.876
    Renommee
    283

    AW: Assembler, Speicher und Netzwerk

    Das letzte Posting ist noch immer "akut" - Hilfe gesucht!

    Was ich mich auch noch frage ... der/die CPU-Cache(s) ist/sind ja der schnellste Speicher im System, also in erster Linie die Register (und Flags).

    Ist das nicht ein *ziemlicher* Flaschhals, dass immer nur schrittweise bspw. aus dem (langsameren) Arbeitsspeicher die Daten in die CPU geladen
    werden müssen!? Gibt's da evtl. andere Ansätze, die man noch in ASM umsetzen müsste? Hatte z.B. gedacht, wenn ich mit 16-Bit-Daten arbeite,
    oder gar mit einfachen Bytes, so kann ich je nachdem (64/16) 4x bzw. (64/8) 8x schneller rechnen lassen, wenn ich schon im Vorfeld gegebene
    Daten (Bytes oder eben Words) in einer einzigen Operation in die Caches lege und dann bloß noch die entsprechende Sub-Adressen ansprechen?

    Ich denke, so etwas gibt's in den CPUs selbst schon, oder? Einziges Problem (davon ab, dass nicht immer schon vorher die Daten feststehen) wäre
    dann noch, dass größere Datensätze trotzdem aus dem RAM rüber-geschaufelt werden müssten. ... kann man das nicht irgendwie "von Innen heraus"
    auflösen o.ä.? Evtl. sogar eine Form der Kompression, die direkt innerhalb der CPU(-Caches/-Gatter) laufen würde? Evtl. ja so ähnlich wie Brainfuck? *gg*

    Just some thoughts ... das eigentliche Problem bleibt mein letztes Posting, wie gesagt.

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  5. #5
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.876
    Renommee
    283

    AW: Assembler, Speicher und Netzwerk

    OffTopic:
    Zelluläre Modelle.pdf Ein Teil der Raumzeit agiert eben so. ... oder!? (^_^)°

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  6. #6
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.876
    Renommee
    283

    AW: Assembler, Speicher und Netzwerk

    So weit ich jetzt informiert bin, sollte wohl ein Bootloader immer zuerst in Assembler codiert werden,
    weil der Speicherplatz dann genau(er) einzuplanen ist - vor allem die "Magic Number".

    Kann man diese ("0xaa55") nicht einfach durch einen C-Pointer mit vorgeben, der genau auf die nötige
    Adresse (511 & 512) referenzieren würde? Dann wäre somit ja auch ein C-Bootloader besser denkbar?

    Code:
    short * magic = (short *)0x1ff

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  7. #7
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.876
    Renommee
    283

    AW: Assembler, Speicher und Netzwerk

    Natürlich wäre die "0x1ff" eine Adresse relativ zum ersten Festplatten-Sektor, glaube ich btw. ... wäre also noch zu überprüfen, woher ich dir absolute Adresse bekomme;
    sonst würde ich ja vermutlich einen Zeiger zur "main"-Funktion verwenden, aber das gilt auch bloß im Speicher, nicht auf der Festplatte. Fehlt also theoretisch noch was; hm?!

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. Antworten: 2
    Letzter Beitrag: 12.08.2003, 19:45
  2. DLL im Speicher
    Von thodi im Forum Windows
    Antworten: 3
    Letzter Beitrag: 19.07.2003, 20:27
  3. DOS: 3 MB EMS Speicher!
    Von das_opfer im Forum Technisches Off-Topic
    Antworten: 9
    Letzter Beitrag: 13.02.2002, 14:01
  4. Antworten: 2
    Letzter Beitrag: 15.08.2001, 20:22
  5. Speicher Groesse
    Von code_x im Forum Systemnahe Programmierung
    Antworten: 1
    Letzter Beitrag: 07.11.2000, 23:42

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •