perl direkt in assembler? (Seite 2) (Allgemeines zu Perl)

[thread]7251[/thread]

perl direkt in assembler? (Seite 2)

murphy

2005-09-04 01:58

User since
2004-07-19
1776 Artikel
HausmeisterIn

[quote=jemand,03.09.2005, 23:37][...]
Gut natürlich könnte der Compiler jeder Variable eine überprüfung zuschieben die dann eben schaut ob die Variable größer ist und ihr mehr Platz zukommen lässt. Das wird dann aber groß und ist schlecht optimierbar für den Compiler und somit auch wieder langsam.
[...]
Btw.: Kennt irgendjemand einen Compiler der nichts von Variablentypen und Arraylängen wissen will?
[...][/quote]
Gerade das ist eben gar nicht so lahm und groß. Die Verwaltung allozierten Speichers nimmt natürlich ein wenig Rechenzeit in Anspruch -- aber teilweise kann man das automatisch sogar deutlich effizienter machen als von Hand, was daran liegt, dass es dem Rechner oftmals lieber ist, wenn man pauschal große Blöcke Speicher reserviert und diese sinnvoll nutzt, anstatt viele kleine Speichereinheiten zu allozieren.

Und zu der Frage kann ich dir meinen Lieblings Scheme Compiler CHICKEN empfehlen ;-) Scheme hat bei der Kompilation sogar noch ein paar weitere hässliche Probleme, die Perl nicht hat, und trotzdem geht's...

When C++ is your hammer, every problem looks like your thumb.

murphy

2005-09-04 02:11

User since
2004-07-19
1776 Artikel
HausmeisterIn

[quote=betterworld,03.09.2005, 23:57]Ich meinte eigentlich nicht [/i]variable[/i] regulaere Ausdruecke, sondern alle. Denn ich ging davon aus, dass man die regulaeren Ausdruecke nicht auch in Assemblercode umwandeln moechte. [...][/quote]
Warum sollte man die regulären Ausdrücke nicht auch kompilieren? Gerade das könnte meiner Meinung nach einen schönen Geschwindigkeitsvorteil bringen, weil man die exzellent optimiert kompilieren kann!

[quote=betterworld,03.09.2005, 23:57]Jedenfalls wird es eine widerliche Angelegenheit, zur Laufzeit Maschinencode zu erzeugen, der dann irgendwo in den Speicher gepackt wird und von dort aus ausgefuehrt wird; und genau das ist fuer eval ja noetig.[/quote]
<haarspalterei>Codegenerierung zur Laufzeit ist zwar eine Variante, eval zu implementieren, aber nicht die einzige. Es gibt da noch so einen echt coolen Trick mit continuation passing style, mit dem man sich eine aus einem vorher angelegten Vorrat an Routinen zur Laufzeit ein beliebiges Programm basteln kann, ohne dazu neuen Maschinencode in den Speicher schreiben zu müssen.</haarspalterei>

[quote=betterworld,03.09.2005, 23:57]So oder so muesste man perl so ziemlich neu schreiben.[/quote]
Das halte ich eben auch für ein wichtiges Problem.

When C++ is your hammer, every problem looks like your thumb.

sri

2005-09-04 02:58

User since
2004-01-29
828 Artikel
BenutzerIn

JIT Compiler sind fuer dynamische Sprachen viel sinnvoller.
Pugs und Parrot unterstuetzen jedenfalls eine Menge compiler backends.

http://mojolicio.us/

esskar

2005-09-04 05:03

User since
2003-08-04
7321 Artikel
ModeratorIn

user image

@jemand:

ich versteh nicht was du willst.
Ich kenne keine vernünftige, kompilierbare Programmiersprache, in der es nicht möglich, eine dynamisches Array (oder sonst ähnliches) zu erstellen.
aber ich weiß ja nicht, was du sonst so programmierst! ;)
ich denke, eval macht die größten Probleme.

aber da es ja ***bald*** Perl 6 gibt (geben soll), erübrigt sich das eh.

sri

2005-09-04 07:14

User since
2004-01-29
828 Artikel
BenutzerIn

[quote=esskar,04.09.2005, 03:03]aber da es ja ***bald*** Perl 6 gibt (geben soll), erübrigt sich das eh.[/quote]
s/***bald***//

Pugs! ;)

http://mojolicio.us/

supersucker

2005-09-04 07:51

User since
2005-03-17
118 Artikel
BenutzerIn
[default_avatar]

@jemand:

Quote
Der Speicher für entsprechendes muss erst reserviert werden. In C(++) gibt man deshalb bei der definition eines Array immer an wie lang es sein muss und bei Variablen einen spezifischen Typ. Dadurch weiß der Compiler wie viel Speicher(im Ram oder direkt Register) er reservieren muss.

Quote
Wie willst du das Problem variablen Speichers mit Pointern lösen? Versteh ich irgendwie nicht...

ja, das trifft sich, ich versteh auch nicht was du meinst....:-)

In C(++) gibt man deshalb bei der definition eines Array immer an wie lang es sein muss.....bitte??

wenn du also in C++ programmierst, überlegst du also jedes mal wenn du irgendwas mit speicherstrukturen machst wie gross die maximal werden können, und allokierst entsprechend viel speicher oder wie hab ich das zu verstehen?
der C++-Compiler muss beim kompilieren nicht wissen wie lang ein array ist, wäre ja auch ziemlicher unsinn...
ich hab noch keine ernstzunehmende sprache gesehen in der es nicht möglich wäre array o. Ä. zur laufzeit wachsen zu lassen, dann wäre ja programmieren ein lustiges rätselraten wie lang denn das ding nun wird.

jemand

2005-09-04 12:21

User since
2004-05-14
231 Artikel
BenutzerIn
[default_avatar]

Oke oke, ich nehm alles Arraymäßige zurück. Ich war nur verwirrt da ich nur mit Avr-C wirklich was mache und da wächst definitiv nichts zur Laufzeit. <auch haarspalterei>Achja dieses "oder sonst ähnliches" macht es eben. Vector != Array...</auch haarspalterei>

@"***bald*** perl 6 gibt": Na wenn da noch gewisse Leute unbedingt Japanisch lernen wollen dauerts wohl noch weng... :cool:

@supersucker: Wenn ich also Avr-C programmiere schaue ich wie lang ein String wird und gebe dem Array eine Länge die der des Strings+1 entspricht, damit der liebe Compiler dann noch \0 anhängen kann. Das ist definitiv richtig so.

print uc 'i',chr(29*4).q+'s +.++($_=q-m-),++$_;
print chr for 116,$_[0],97,$_[0],98;
print 'ug,',chr(), scalar reverse qq?!erutaef a s'ti?;

esskar

2005-09-04 13:48

User since
2003-08-04
7321 Artikel
ModeratorIn

user image

ich kenn Avr-C nicht, aber in normalen C geht das so

Code: (dl )

#include <stdio.h>

char *StrCreate(const char *str) {
   int len;
   char *retval;

   if(str == NULL) return NULL;

   len = strlen(str);
   retval = (char *)malloc(len + 1);
   strncpy(retval, str, len);

   return retval;
}

char *StrConcate(char *str1, const char *str2) {
    int len1, len2;

    if(str1 == NULL) return NULL;
    if(str2 == NULL) return str1;
    
    len1 = strlen(str1);
    len2 = strlen(str2)
    str1 = (char *)realloc(str1, len1 + len2 + 1);
    strncpy(str1+len1, str2, len2);

    return str1;
}

int main(int argc, const char *argv[]) {
    char *string;

    string = StrCreate("Das ist ein String!\n");
    printf("%s", string);
    string = StrConcate(string, "Noch mehr Text\n");
    printf("%s", string);

    return 0;
}

ein char * ist ja quasi ein Array (kein vector) of char's; das selbe geht mit allen anderen typen oder structuren

betterworld

2005-09-04 15:35

User since
2003-08-21
2613 Artikel
ModeratorIn

user image

Ich weiss nicht, Ihr an der Speicherverwaltung das grosse Problem seht. _Technisch_ gesehen laesst sich alles in Assembler loesen, was sich in Perl loesen laesst, denn Perl kocht ja letztendlich auch auf Assembler runter: perl ist in C geschrieben, C wird nach Assembler uebersetzt.

Lieblingsmodule: CPAN:

IPC::System::Simple, CPAN:

Path::Class

sri

2005-09-04 19:51

User since
2004-01-29
828 Artikel
BenutzerIn

[quote=betterworld,04.09.2005, 13:35]Ich weiss nicht, Ihr an der Speicherverwaltung das grosse Problem seht. _Technisch_ gesehen laesst sich alles in Assembler loesen, was sich in Perl loesen laesst, denn Perl kocht ja letztendlich auch auf Assembler runter: perl ist in C geschrieben, C wird nach Assembler uebersetzt.[/quote]
Aber es ist ein bytecode interpreter dazwischen, vermute da liegt auch der denkfehler, "jemand" wollte Perl quellcode dierekt nach C(++) uebersetzen.\n\n

http://mojolicio.us/

View all threads created 2005-09-03 18:00.