Quellcode per Include zusammenfügen

> Gibts da ne lösung für ?

Das klingt alles aber sehr danach, dass du viel grundlegendere Probleme 
beim Codeschreiben hast, die du dadurch nur kaschieren willst anstatt 
die Probleme an sich anzugehen.

Hey

Peter II
Ich programmier in Assembler. Dazu benutze ich "TextPad" mit entspr.
Syntax-highlighting. Als Assembler nutze ich AVRASM32.exe

Karl Heinz
Bin wirklich nicht der Profi Programmierer. Kann sein das ich Probleme 
hab von denen ich selber garnichts weiss. Ich weiss es eben nicht besser 
:)
Was glaubst du denn genau was ich fürn Problem habe ?

Hans Imglück schrieb:

> Was glaubst du denn genau was ich fürn Problem habe ?


Das du eine elende Wurst an Programm runterschreibst 
(Spaghettiprogrammierung) und keine vernünftige Aufteilung in 
Subroutinen machst. Denn für die ist es völlig egal, wo sie im Speicher 
stehen. Sie werden aufgerufen, machen ihr Ding und kehren dann wieder 
zur Aufrufstelle zurück.

In C sind das Funktionen, in Assembler Unterprogramme.

Einzelne Funktionen kannst du doch Problemlos auslagern, die werden 
genau da in den Hexcode eingefügt, wo du die Funktion aufrufst.

Du weisst aber schon, dass man auch mehrere Source Files Assemblieren 
und dann Linken kann?

Karl Heinz
Ganz so schlimm ist es auch nicht. Ich arbeite schon mit Unterprogrammen 
die im Prinzip irgendwo im Speicher stehen könnten.
Es ist nur so, das der gesamte Quelltext mittlerweile recht lang 
geworden ist. So das ich immmer viel zu scrollen hab wenn ich eine 
bestimmte Passage suche.
Programteile die fertig sind und nicht mehr geändert werden möchte ich 
darum in Include dateien auslagern.
Dennoch hätte ich gerne die "Include"-Anweisungen am Anfang des 
Quelltextes stehen. Der eigendlich Programmcode soll aber eben nicht am 
anfang stehen.
Daher die Frage ob ich der Include anweisung einen Parameter mitgeben 
kann, an welcher stelle er den code einfügen soll.

Hans Imglück schrieb:

> Dennoch hätte ich gerne die "Include"-Anweisungen am Anfang des
> Quelltextes stehen.

Dann erhebt sich doch die Frage: WOzu?

Was bringt es dir, wenn du die include am Anfang zusammenfasst.

> Daher die Frage ob ich der Include anweisung einen Parameter mitgeben
> kann, an welcher stelle er den code einfügen soll.

include macht Textersetzung. Die Zeile mit dem include wird durch den 
Inhalt der Datei ersetzt.
Es steht dir natürlich frei im zu inkludierenden File den Programmtext 
mittels eines .org an eine bestimmte Position zu locken, aber sinnvoll 
ist das deswegen auch nicht. Denn irgendwie musst du nun mal die 
Position markieren, wo du den Text hinhaben willst. Und ob dort dann ein 
Label steht, auf das du dich mit einem .org beziehen kannst oder ein 
.include, ist dann auch schon egal. Dann lieber einen .include. Da kann 
dann wenigstens ein Blinder greifen, dass da Code reinkommt.

Trotzdem solltest du deine Strukturierung in Funktionen überdenken. Wenn 
ein Programmteil eine gewisse Größe überschritten hat, ist es immer 
sinnvoll ihn durch Aufteilung in funktionale Gruppen zu unterteilen, die 
dann mehr oder weniger beliebig im Speicher verschoben werden können.

Und gegen das Problem des 'da muss ich aber dauernd Scrollen, wenn ich 
was nachschlagen will', haben die IDE-Bauer Editoren erfunden, die ein 
und denselben Source in mehreren Fenstern gleichzeitig darstellen 
können.

Karl Heinz
Die Diskussion könnten wir noch monatelang weiterführen.
Ich beende das aber mal an dieser Stelle da ein einfaches
 "Nein, geht nicht" gereicht hätte.

Krümeltee
"mehrere Source Files Assemblieren
und dann Linken"
Nee, wusste ich nicht. wie genau geht das ?

Wie du das mit deinem Assembler machst, kann ich dir nicht sagen - ich 
bin gas/avra-User, wenn ich was in Assembler mache.
Nutzt du z.B. das AVR-Studio, dann erstelle einfach mehrere Source Files 
im Projekt.

Hans Imglück schrieb:
> "mehrere Source Files Assemblieren
> und dann Linken"
> Nee, wusste ich nicht. wie genau geht das ?

Das genau ist das, was "kein name" schon um 20 nach sechs angedeutet 
hat:

Modulares Programmieren.

Hätte ja sein können das irgend jemand ne lösung kennt, die "Kein Name" 
um 20 nach sechs noch nicht kannte. Die Hoffnung stirbt zuletzt oder so 
:)

spess53 schrieb:
> Hi
>
>>Das genau ist das, was "kein name" schon um 20 nach sechs angedeutet
>>hat:
>
>>Modulares Programmieren.
>
> Das ist ja nicht das Problem. Nur möchte der TO seine Include-Files
> vor dem Hauptprogramm, warum auch immer, einfügen.

Und ich wüsste immer noch keinen Grund, geschweige denn das ich das 
Ansinnen verstehen würde, warum ich das überhaupt will.

Mit dem Atmel Assembler kann man nicht linken. Und? Was solls.

Dann stehen da halt

1

.include "m8def.inc"

2

3

      rjmp init

4

5

      interrupt Vektoren

6

7

init:

8

    hier mein Programm, 3 bis 4, vielleicht 5 Bildschirmseiten

9

    ...

10

11

.include "uart.inc"

12

.include "lcd.inc"

13

.include "mathfunc.inc"

14

.include "linerare Interpolation.inc"

15

.include "keine Ahnung was noch.inc"

16

.include "wahsinnig wichtige Hilsfunktionen.inc"

17

.end

Hahaha
OmG, Was hab ich da nur angerichtet ? :)
War ja nur so eine idee. Wenns nicht geht dann gehts eben nicht.
Liegt wohl an meinem Sortierwahn , das ich meine Includes alle im 
Programmkopf untereinander auflisten wollte.

Spess 53
Habs grad mal versucht, klappt aber so einfach nicht.

Peter II
Die Idee ist gut. Gefällt mir.

Wenn das Programm mal fertig ist bringt das sicher nichts mehr. Dann 
werd ich auch wieder alles in einer Datei zusammenpacken.
Während der Programmierphase find ichs einfach übersichtlicher , weil 
man eben nicht so einen riesigen unübersichtlichen Textwust hat.
Ausserdem kann man ausgelagerte Programmteile nicht mehr aus versehen 
verändern was mir durch drücken irgendeiner Tastenkombination (zu dicke 
Finger) schon passiert ist.
War wie gesagt auch nur so eine Idee. Ob es mir tatsächlich Vorteile 
bringt werd ich ja sehen. Ich versuchs einfach mal.

Kein Name schrieb:
>> OmG, Was hab ich da nur angerichtet ? :)
>
> Programmierer sind halt fundamentalistische Bauhaus-Anhänger. Wenn die
> Form nicht der Funktion entspricht, betrachten wir es als Angriff auf
> unser ästhetisches Empfinden.

Schön gesagt.
Die Sache ist allerdings subtiler.

Denn es zeigt sich, dass die generelle Funktion (=das Funktionieren) in 
eigenartiger Weise mit der Form verknüpft ist. Im Laufe der Zeit haben 
sich Formen herauskristallisiert, die funktionieren und es hat sich 
gezeigt, dass Formabweichungen sehr oft mit allen möglichen Abstufungen 
der Nichtfunktion einhergehen.

Oder wie ich immer gerne sage:
Hier im Forum sieht man sehr oft ganz deutlich - die mit den 
scheuslichsten und unübersichtlichsten Programmen, diejenigen die sich 
die Dinge zu sehr verstecken sind oft auch diejenigen, bei denen die 
Programme nicht funktionieren. Bring das Programm auf die Standardform 
und oft werden die Denkfehler und/oder sonstigen kleinen Fehlerchen 
sowohl für den Formkundigen als auch für den Lernenden offensichtlich.
Von daher ist es meistens keine gute Idee, wenn man bewährte Formen 
ausser acht lässt.