amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > StormC 4 oder GoldED Studio AIX: C/C++ IDE [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- [ - Beitrag schreiben - ]

14.07.2005, 09:12 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Nein, streng genommen ist das einzige Problem, den PPC-Code ins Hunk-Format zu kriegen und dann einen passenden Linker zu haben, der daraus (ggf. zusammen mit 68K-Code) ein funktionsfähiges Executable macht. Ich entsinne mich noch dunkel an die "Krücke" aout2hunk für die ersten AOS68K-GCCs...

Hmm, ich kann mich erinnern, daß ich damals für powerup eine ziemlich einfache Lösung hatte, bei der das ELF binary, so wie es war, in das 68k Programm eingebettet wurde. Ganz so, wie mancher größere textpassagen oder Bilddaten included hat.
Die powerup-lib hatte eine Funktion, die das ELF-file auch direkt aus dem RAM laden konnte.


So ähnlich kann man es auch mit WOS machen, allerdings verlierst Du dann die simple Möglichkeit, fat binaries zu erzeugen.

Denk immer daran, daß WOS, wie wir es jetzt kennen, genau wie PUP einen Übergang darstellen sollte...

Zitat:
Zitat:
Um ehrlich zu sein: Mir persönlich wäre es lieber, wenn man die adtools-Initiative nutzt, den GCC immer fein aktuell hält in allen Geschmacksrichtungen und dazu passend eine schöne, leicht bedienbare und komfortable IDE zimmert.
Klingt nach einer guten Sache. Ist wie immer eine Frage nach Aufwand und Resourcen.

Wenn ich genau wüßte, daß ich über kurz oder lang nicht ganz allein daran basteln muß... 8)

Zitat:
Zitat:
Die könnte man wahlweise auch in 68K halten, da dieses ja auf allen Systemen (Ausnahme AROS, aber das sollte kein großes Problem sein) läuft. Dann leidet die Geschwindigkeit gerade auf echten 68K-Systemen zwar spürbar, aber wozu gibts WinUAE/Amithlon? I-)
Leidet die Geschwindigkeit auf echten 68K-Systemen, weil es die Software dann überhaupt für solche Systeme gibt? Oder meinst Du, weil alle Entwickler nur an 68k-emu Systemen arbeiten und keiner mal auf "classic" testet?

Weder noch. Wenn Du den 2.95.x-GCC mal auf nem 060er laufen läßt, weißt Du, was ich meine. Da war der StormC3 schon ein wenig im Vorteil, weil viel schneller. Leider kann der in Sachen C++ halt nicht mithalten. Noch krasser wirds mit dem GCC 3.x, wie das mit dem 4.x aussieht, will ich ehlrich gesagt gar nicht wissen I-)

Die IDE ist, wenn man nicht gerade krampfhaft portabel arbeiten muß, das geringste Problem dabei :lach:

Zitat:
Zitat:
Oder man baut ein Amiga-spezifischer Debugger, der sich einfach in eine solche IDE einbinden läßt.
Ja wenn wir alle mehr Zeit hätten... Auf Schlaf, Freizeit und Job kann man ja verzichten...aber selbst dann sind's nur 24h/d.

Hm, ich denke, so aufwändig ist ein Debugger auch wieder nicht. Zumindest muß er ja nicht aus dem Stand heraus "full featured" und perfekt sein, oder? :D

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 14.07.2005 um 09:13 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 10:09 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
Zitat:
gni:
Mit etwas gutem Willen könnte man das ARexx-Interface aus den StormGCC Quellen extrahieren und dann aktuellere Versionen benutzen, allerdings eben nicht für WarpOS.

Soll heißen, mit WarpOS als target?
Ja.
Zitat:
Inwieweit braucht man eigentlich tatsächlich aktiven support dafür?
Von Hause aus hat GCC keine Einstellung, um WarpOS kompatiblem Code zu erzeugen. Und genau das hat H&P in GCC eingebaut (allerdings inkompatibel zu StormC 3!), aber eben nur für GCC2. GCC3 Anpassung ist Arbeit.
Zitat:
Letztendlich gibt's ja auch ne pup-emu. Also prinzipiell kann man auch konventionellen ppc-code ausführen und alles, worum es Programmierern geht, ist doch ppc-code und 68k-code in einem executable zu verpacken, dem man von außen nicht ansieht, was da alles kompliziertes passiert, oder?
Abgesehen davon, das nicht jedes Programm mit der Emu funktioniert, ist die notwendige Umsetzung der verschiedenen ABI unsauber. Bei WarpOS/EHF kann man das Mischen von 68k und PPC Code vom Linker erledigen lassen. Für ELF braucht man einen Zwischenschritt, der aus dem fertigen PPC-Programm ein 68k-Objekt macht, das man dann zum 68k Code linken kann. So macht das zb. mpega_libmad.

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 10:18 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
Hmm, ich kann mich erinnern, daß ich damals für powerup eine ziemlich einfache Lösung hatte, bei der das ELF binary, so wie es war, in das 68k Programm eingebettet wurde. Ganz so, wie mancher größere textpassagen oder Bilddaten included hat.

Da gibt es verschiedene Programme, zb. Data2Object. Damit wird aus dem ELF Programm ein Objektfile gemacht, das man dann zum 68k, linkt.
Zitat:
Die powerup-lib hatte eine Funktion, die das ELF-file auch direkt aus dem RAM laden konnte.
PPCLoadObjectTagList() kann ein ELF-Programm sowohl aus einem File als auch aus dem Speicher laden. Eingebette ELF-Programme "verschwenden allerdings etwas Speicher, haben aber den Vorteil, daß man den ELF-Loadsegpatch nicht benötigt.

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 10:37 Uhr

Solar
Posts: 3680
Nutzer
Ich mein' das jetzt ganz ernst, weil ich nicht ganz auf dem Laufenden bin: Wie sieht es eigentlich mit Java-Unterstützung auf AOS4 / MOS aus? Ist da überhaupt etwas in Arbeit?

Dann könnten sich echte Optimisten ja auf Eclipse als IDE freuen... I-)

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 13:48 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Solar:
Ich mein' das jetzt ganz ernst, weil ich nicht ganz auf dem Laufenden bin: Wie sieht es eigentlich mit Java-Unterstützung auf AOS4 / MOS aus? Ist da überhaupt etwas in Arbeit?

Dann könnten sich echte Optimisten ja auf Eclipse als IDE freuen... I-)


Guggst Du hier.


Aber für Elipse muß man wirklich noch ein echter Optimist sein I-)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 14:56 Uhr

Dietmar
Posts: 166
Nutzer
Zitat:
Welches der beiden ist besser? StormC 4 oder GoldED Studio AIX: C/C++ IDE?

Bezüglich StormC/GoldED würde ich denen, für die StormC in Frage kommt, also OS3-Entickler, beides empfehlen: GoldED als Editor, StormC als IDE. GoldED mag aktuellere Compiler enthalten aber der Debugger in StormC (und die andere Tools) ist den Kauf schon alleine wert. GoldED war Bestandteil des kommerziellen StormC3-Paketes, deshalb kann er gut mit StormC benutzt werden und z.B. dessen Debugger-Breakpunkte anzeigen. Die StormC-Shell hat einen Tooltype, mit dem man zwischen StormED und GoldED wählen kann. GoldED sollte auch noch mit StormC4 funktionieren (?). In dem Fall darf man GoldED nur mit dem vbcc-Compiler installieren und muss das Thema gcc der StormC-IDE überlassen. In GoldED wählt man für C-Quelltexte den Dateityp "StormC".

Wer GoldED mal ausprobieren möchte aber keine Lust hat, dafür 160 MB herunterzuladen, kann mir eine leere CD-R im Rückumschlag schicken (Rückumschlag muss frankiert sein, sonst kommt nichts zurück). Das Angebot gilt bis Ende des Monats, wie der GoldED-Coupon in der neuen Ausgabe der AmigaInsider.

http://www.dietmar-eilert.net/contact.htm

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 16:52 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von gni:
PPCLoadObjectTagList() kann ein ELF-Programm sowohl aus einem File als auch aus dem Speicher laden. Eingebette ELF-Programme "verschwenden allerdings etwas Speicher, haben aber den Vorteil, daß man den ELF-Loadsegpatch nicht benötigt.

Könnte man doch mit overlay-hunks kombinieren...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 16:59 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
So ähnlich kann man es auch mit WOS machen, allerdings verlierst Du dann die simple Möglichkeit, fat binaries zu erzeugen.

Wieso, das entspricht doch so ziemlich einem fat binary, der Unterschied liegt doch nur darin, ob man zusätzlich zum ppc-code auch noch eine 68k-Version des entspr. Programmteils einbettet.
Zitat:
Zitat:
Klingt nach einer guten Sache. Ist wie immer eine Frage nach Aufwand und Resourcen.
Wenn ich genau wüßte, daß ich über kurz oder lang nicht ganz allein daran basteln muß... 8)
Mich reizt das auch, aber mit freier Zeit sieht's ziemlich problematisch aus.
Zitat:
Hm, ich denke, so aufwändig ist ein Debugger auch wieder nicht. Zumindest muß er ja nicht aus dem Stand heraus "full featured" und perfekt sein, oder? :D
Bei einem Debugger ist die erste Minimalversion das schwierige, insb. wenn man den code nicht debuggen kann...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 23:30 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
So ähnlich kann man es auch mit WOS machen, allerdings verlierst Du dann die simple Möglichkeit, fat binaries zu erzeugen.

Wieso, das entspricht doch so ziemlich einem fat binary, der Unterschied liegt doch nur darin, ob man zusätzlich zum ppc-code auch noch eine 68k-Version des entspr. Programmteils einbettet.

Argh! Ich meinte mixed binary. Mea culpa. Da isses ja nicht so einfach, da man z.B. bei PUP auf Gate-Funktionen angewiesen ist, die in den 68K-Code eingebaut werden müßen (wenn ich das richtig geblickt habe, wird das z.B. bei MOS hauptsächlich mit Macros erledigt?).

Bei WOS macht das der Linker, daher kann man mit einem Compiler- (bzw. Linker-) Switch aus dem Mixed ein reines 68K- oder PPC-Binary machen.
Oder eben aus einer ehemaligen Nur-68K-Anwendung einen 68K-WOS-Mix, indem man einen Teil der 68k-Funktionen einfach durch den PPC-Compiler jagt und später das Ganze zu einem Mixed Binary linken läßt. Das war vor allem der große Vorteil von WOS: Man mußte (meistens) an den 68K-Programmen nichts ändern, ein weiterer Compilerlauf, bei dem die für WOS vorgesehenen Funktionen entsprechend ins Projekt eingefügt wurden, genügte meist.

Zitat:
Zitat:
Zitat:
Klingt nach einer guten Sache. Ist wie immer eine Frage nach Aufwand und Resourcen.
Wenn ich genau wüßte, daß ich über kurz oder lang nicht ganz allein daran basteln muß... 8)
Mich reizt das auch, aber mit freier Zeit sieht's ziemlich problematisch aus.

Hm, ich halts da mit "gut Ding will Weile haben". Wenn ich jemanden dabei hätte, mit dem ich mich austauschen kann und der mir dann und wann den Wald zeigt, den ich vor lauter Bäumen nicht sehe (und umgekehrt natürlich auch ;) ), dann kommt Spaß an der Sache auf. Dann zählt die tatsächlich benötigte Zeit nicht so. Im Endeffekt verkürzt das die Zeit, die benöigt wird, weil entsprechend Motivation da ist.

Ich denke mal nicht, daß man in dieser Hinsicht unbedingt was vom Zaun brechen muß. Hauptsache, es passiert überhaupt was. Ist allerdings meine rein persönliche Sicht der Dinge, ich weiß nicht, wie Du das siehst.

Zitat:
Zitat:
Hm, ich denke, so aufwändig ist ein Debugger auch wieder nicht. Zumindest muß er ja nicht aus dem Stand heraus "full featured" und perfekt sein, oder? :D
Bei einem Debugger ist die erste Minimalversion das schwierige, insb. wenn man den code nicht debuggen kann...

Das ist wohl wahr. Andererseits sind inzwischen genug Techniken bekannt, die sowohl in der Theorie als auch in der Praxis funktionieren. Vielleicht mache ich mir die Sache hier etwas zu einfach, aber wenn man den Debugger nach praxiserprobten Theorien baut, dürfte auch die erste Version (mit minimalem Funktionsumfang) nicht so besonders schwierig auf die Beine zu stellen sein. Darauf aufzubauen und weiterzuentwickeln ist dann, denke ich, auch nicht mehr so schwer.

Abgesehen davon sind für alle Systeme bereits Debugger/Tools vorhanden, die man zum Debuggen des Debuggers einsetzen könnte :D

Ich schätze mal, da schlägt die Crux Amiga wieder zu: Der Anfang ist das schwierigste, weniger wegen der Technik sondern mehr wegen dem inneren Schweinehund I-)

Interesse an der Sache habe ich jedenfalls, und ich lerne immer gern dazu. Nen Debugger habe ich noch nie selbst gebaut. Von nem kompletten IDE ganz zu schweigen I-)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

15.07.2005, 09:30 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
Zitat:
gni:
PPCLoadObjectTagList() kann ein ELF-Programm sowohl aus einem File als auch aus dem Speicher laden. Eingebette ELF-Programme "verschwenden" allerdings etwas Speicher, haben aber den Vorteil, daß man den ELF-Loadsegpatch nicht benötigt.

Könnte man doch mit overlay-hunks kombinieren...
AFAIK, das geht nicht für shared Libraries.

[ - Antworten - Zitieren - Direktlink - ]

15.07.2005, 09:51 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Ich meinte mixed binary. Mea culpa. Da isses ja nicht so einfach, da man z.B. bei PUP auf Gate-Funktionen angewiesen ist, die in den 68K-Code eingebaut werden müßen (wenn ich das richtig geblickt habe, wird das z.B. bei MOS hauptsächlich mit Macros erledigt?).

Die Initialisierungsfunktionen schreibt man genau *ein* mal und dann werden sie recycled. Ich sehe da keine wirkliche Einschränkung. Das Nachrichtensystem zu verstehen, ist da schon schwieriger. Steve Kruegers Beispiele (zu finden beim SAS/C PPC) sind da hilfreich.
Zitat:
Bei WOS macht das der Linker, daher kann man mit einem Compiler- (bzw. Linker-) Switch aus dem Mixed ein reines 68K- oder PPC-Binary machen.
Oder eben aus einer ehemaligen Nur-68K-Anwendung einen 68K-WOS-Mix, indem man einen Teil der 68k-Funktionen einfach durch den PPC-Compiler jagt und später das Ganze zu einem Mixed Binary linken läßt. Das war vor allem der große Vorteil von WOS: Man mußte (meistens) an den 68K-Programmen nichts ändern, ein weiterer Compilerlauf, bei dem die für WOS vorgesehenen Funktionen entsprechend ins Projekt eingefügt wurden, genügte meist.

Auch wenn Dir die IDE etwas Arbeit abnimmt, Gatefunktionen werden *auch* bei WOS benötigt. Wobei sich mir die Frage aufdrängt, die Gatefunktion bekommt den Namen der aufzurufenden Funktion, den den selben Namen als PPC Funktion hat. Wie löst man das Dilemma?

[ - Antworten - Zitieren - Direktlink - ]

15.07.2005, 11:25 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von gni:
Zitat:
Holger:
Könnte man doch mit overlay-hunks kombinieren...

AFAIK, das geht nicht für shared Libraries.
Hmm, AFAIR gab es doch sowieso keine Implementierung seitens AmigaDOS, so daß man bei Bedarf ohnehin manuell nachladen muß. Einzige Schwierigkeit bei shared libs wäre, aus dem Initialisierungskontext die zugehörige Datei zu ermitteln. Wie schwer das war/ist, kann ich mich nicht mehr erinnern.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

15.07.2005, 14:43 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Auch wenn Dir die IDE etwas Arbeit abnimmt, Gatefunktionen werden *auch* bei WOS benötigt. Wobei sich mir die Frage aufdrängt, die Gatefunktion bekommt den Namen der aufzurufenden Funktion, den den selben Namen als PPC Funktion hat. Wie löst man das Dilemma?


Das Gatefunktionen benötigt werden, stimmt. Allerdings muß man sie bei WOS nicht im 68K-Code einbauen, dort ist also _keine_ Anpassung nötig (ich erinnere mich nur noch dunkel an das Poseidon-DevKit, da tauchte alle paar Zeilen ein "#ifdef" "DECLGATE"-Konstrukt auf. Nicht besonders gut lesbar, wenn man nur an der 68K-Variante interessiert ist :D ).

Genau das ganze Drama erledigt bei WOS der Linker. Auch die Namensauflösung. Soweit ich mich erinnere, kommt vor jede ehemalige 68K-Funktion bei einem Mixed Binary ein _PPC..., darüber "weiß" der Linker ja Bescheid. Also kein Namenskonflikt.

Daher ists ja auch (eigentlich, die libmad z.B. weicht von dem Schema gewaltig ab I-) ) simpel, aus 68K-Programmen WOS-Programme zu machen. Ein Compiler-Linker-Zyklus ohne Source-Anpassungen (man muß nur das Projekt mit ein paar Klicks umsortieren) genügt (normalerweise).

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

15.07.2005, 16:15 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
ich erinnere mich nur noch dunkel an das Poseidon-DevKit, da tauchte alle paar Zeilen ein "#ifdef" "DECLGATE"-Konstrukt auf.

Das hat was mit MorphOS zu tun.
Zitat:
Genau das ganze Drama erledigt bei WOS der Linker. Auch die Namensauflösung. Soweit ich mich erinnere, kommt vor jede ehemalige 68K-Funktion bei einem Mixed Binary ein _PPC..., darüber "weiß" der Linker ja Bescheid. Also kein Namenskonflikt.
Wie erkennt der 68k-Compiler, das eine PPC-Funktion aufgerufen wird? Oder erkennt das der Linker?
Zitat:
Daher ists ja auch (eigentlich, die libmad z.B. weicht von dem Schema gewaltig ab I-) ) simpel, aus 68K-Programmen WOS-Programme zu machen. Ein Compiler-Linker-Zyklus ohne Source-Anpassungen (man muß nur das Projekt mit ein paar Klicks umsortieren) genügt (normalerweise).
IMHO, der mpega_libmad Weg ist flexibler und man ist nicht an ein einziges Compilersystem gebunden.

[ - Antworten - Zitieren - Direktlink - ]

15.07.2005, 16:31 Uhr

gni
Posts: 1106
Nutzer
[Doppelposting gelöscht]

[ Dieser Beitrag wurde von gni am 15.07.2005 um 16:32 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.07.2005, 17:58 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
whose:
ich erinnere mich nur noch dunkel an das Poseidon-DevKit, da tauchte alle paar Zeilen ein "#ifdef" "DECLGATE"-Konstrukt auf.

Das hat was mit MorphOS zu tun.

Ja. Ich bin der Meinung, daß das diese Gate-Funktionen sind, weil das Zeugs in Library-(bzw. Poseidon-module) Code auftaucht..

Zitat:
Zitat:
Genau das ganze Drama erledigt bei WOS der Linker. Auch die Namensauflösung. Soweit ich mich erinnere, kommt vor jede ehemalige 68K-Funktion bei einem Mixed Binary ein _PPC..., darüber "weiß" der Linker ja Bescheid. Also kein Namenskonflikt.
Wie erkennt der 68k-Compiler, das eine PPC-Funktion aufgerufen wird? Oder erkennt das der Linker?

Das erkennt der Linker, da der Compiler die Funktionen als 68K (Standard- "_") oder eben als PPC-Code (wenn ich mich richtig erinnere "_PPC_") markiert, je nach dem, welche Compiler-Variante zum Einsatz kommt für das betreffende Modul/Funktion. Dementsprechend fügt der Linker die jeweils passende Gate-Funktion (bzw. die 68K-Funktion) für den Aufruf ein.

Das Erstellen der Gates passiert beim StormC im ersten Compilerlauf mit aktivem Debugging, dabei werden die Gatefunktionen automatisch als Source erzeugt, welche der Compiler dann zum Objekt compiliert.

So könnte man (theoretisch) auch den umgekehrten Weg gehen, also aus PPC-Code via Gate 68K-Code aufrufen. Und alles, ohne was an den Sourcen selbst verändern zu müssen...

Ansehen kannst Du Dir das an den Sourcen zur WOS-Version von der libmad, die ich Dir mal geschickt hatte. Kann ich Dir nochmal schicken, falls Du die nicht mehr haben solltest :D

Zitat:
Zitat:
Daher ists ja auch (eigentlich, die libmad z.B. weicht von dem Schema gewaltig ab I-) ) simpel, aus 68K-Programmen WOS-Programme zu machen. Ein Compiler-Linker-Zyklus ohne Source-Anpassungen (man muß nur das Projekt mit ein paar Klicks umsortieren) genügt (normalerweise).
IMHO, der mpega_libmad Weg ist flexibler und man ist nicht an ein einziges Compilersystem gebunden.

Naja, das ist das Ergebnis der Uneinigkeit/der Grabenkämpfe. Wenn die Compiler an WOS angepaßt worden wären (so, wie sie im Endeffekt auch an die jeweiligen ELF-Varianten angepaßt werden mußten), würde sich diese Frage nicht stellen. Genauso könnte man argumentieren, wenn AmigaOS damals von Hunk- auf ELF-Format umgestellt worden wäre, was ja nun auch mit OS4 passiert ist.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 15.07.2005 um 18:13 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]


1 -2- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > StormC 4 oder GoldED Studio AIX: C/C++ IDE [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.