Γλώσσες που υποστηρίζονται σε πολλαπλά λειτοργικά

[defacer]

Όχι, είναι ένας interpreter, πάνω-κάτω σαν όλους τους άλλους.

 

Nitpick: compiler είναι (καί virtual machine ταυτόχρονα). Αλλά συγχωρεμένος γιατί στην αρχή και γω νόμιζα πως είναι interpreter. 

 

Περιμένω τον Defacer να "δώσει τα φώτα" του στο θέμα!

 

Δεν είμαι σίγουρος τι φώτα ακριβώς περιμένεις, πάντως για cross-platform, σε ένα αρχείο που έχει μέσα τα πάντα όλα και τρέχει με διπλό κλικ χωρίς να ασχολείσαι με runtimes κλπ η λύση είναι κάτι του στυλ C++/qt και statically link όλες τις libraries όπως είπε ο mig. Θα βγει πολύ μπουρί το αρχείο (καμπόσα MB) αλλά c' est la vie.

[geomagas]

Nitpick: compiler είναι (καί virtual machine ταυτόχρονα). Αλλά συγχωρεμένος γιατί στην αρχή και γω νόμιζα πως είναι interpreter. 

 

Θα εννοείς τη Zend engine...

 

Συνηθίζω να απλοποιώ τα πράγματα, και θεωρώ compiler οτιδήποτε παράγει cpu-native κώδικα.

Οτιδήποτε γίνεται compile σε μία γλώσσα άλλης μηχανής, είτε το ονομάζει ο ποιητής virtual machine είτε engine, είτε γίνεται JIT είτε AOT, είτε παράγει bytecode είτε οτιδήποτε άλλο, τελικά θα χρειαστεί έναν interpreter για να τρέξει bare-metal.

 

Υποκειμενικό; Ίσως. Αλλά έχω ένα απλό αξίωμα:

 

compiler+VM==interpreter

[migf1]

migf1 είχα δοκιμάσει αυτό που λες αλλά δεν πέτυχε. Πως τελικά γίνεται αυτή η σύνδεση;

 

Τι είχες δοκιμάσει, με ποιον compiler, με ποιες βιβλιοθήκες και σε ποια πλατφόρμα;

 

Ρωτάω γιατί η σύνδεση με βιβλιοθήκες διαφέρει και από πλατφόρμα σε πλατφόρμα και από compiler σε compiler. Για παράδειγμα, με gcc οι στατικές βιβλιοθήκες είναι αρχεία με κατάληξη .a (τα οποία περιέχουν μέσα τους αρχεία .o ... μπορείς να κάνεις link κι απευθείας με κάποιο ή κάποια .o αρχεία).

[defacer]

Συνηθίζω να απλοποιώ τα πράγματα, και θεωρώ compiler οτιδήποτε παράγει cpu-native κώδικα.

Οτιδήποτε γίνεται compile σε μία γλώσσα άλλης μηχανής, είτε το ονομάζει ο ποιητής virtual machine είτε engine, είτε γίνεται JIT είτε AOT, είτε παράγει bytecode είτε οτιδήποτε άλλο, τελικά θα χρειαστεί έναν interpreter για να τρέξει bare-metal.

 

Κι αυτή η τοποθέτηση είναι επίσης έγκυρη μιας και κατά κοινή ομολογία υπάρχει αρκετή άπλα στο πώς κάνει κανείς το διαχωρισμό. Αυτό που λες εσύ είναι ακριβώς το #3 από εδώ ενώ εγώ είχα στο μυαλό μου το #1 που είναι μάλλον μια πιο "αρχαία" οπτική.

 

Eιδικά στην περίπτωση που μιλάμε για "compilation σε δύο πράξεις" (source ==[compiler]==> bytecode ==[jitter]==> native) νομίζω μπορεί κανείς να το βαφτίσει όπως θέλει.

 

Thanks για την τοποθέτηση, με έβαλες σε ενδιαφέρουσες σκέψεις σήμερα.

[geo1st487]

Δεν είμαι σίγουρος τι φώτα ακριβώς περιμένεις, πάντως για cross-platform, σε ένα αρχείο που έχει μέσα τα πάντα όλα και τρέχει με διπλό κλικ χωρίς να ασχολείσαι με runtimes κλπ η λύση είναι κάτι του στυλ C++/qt και statically link όλες τις libraries όπως είπε ο mig. Θα βγει πολύ μπουρί το αρχείο (καμπόσα MB) αλλά c' est la vie.

 

Υπαρχει και η λυση του MoleBox.

http://www.molebox.com

[defacer]

Υπαρχει και η λυση του MoleBox.

http://www.molebox.com

 

Ε ναι αλλά με την ίδια λογική υπάρχει και η λύση του να δίνεις στο χρήστη ένα laptop με το πρόγραμμά σου εγκατεστημένο και να το τρέχει από εκεί. Απλά αντί για virtual machine του δίνεις physical, και έχεις ακριβώς τα ίδια προβλήματα (no access στο μηχάνημα "του χρήστη").

[Kercyn]

 

Θα εννοείς τη Zend engine...

 

Συνηθίζω να απλοποιώ τα πράγματα, και θεωρώ compiler οτιδήποτε παράγει cpu-native κώδικα.

Οτιδήποτε γίνεται compile σε μία γλώσσα άλλης μηχανής, είτε το ονομάζει ο ποιητής virtual machine είτε engine, είτε γίνεται JIT είτε AOT, είτε παράγει bytecode είτε οτιδήποτε άλλο, τελικά θα χρειαστεί έναν interpreter για να τρέξει bare-metal.

 

Υποκειμενικό; Ίσως. Αλλά έχω ένα απλό αξίωμα:

compiler+VM==interpreter

 

Δηλαδή με αυτήν την παραδοχή θα μπορούσαμε να πούμε ότι η Java είναι interpretted γλώσσα;

[geomagas]

Δηλαδή με αυτήν την παραδοχή θα μπορούσαμε να πούμε ότι η Java είναι interpretted γλώσσα;

 

Όχι η ίδια, αλλά το JRE ναι.

Το παράδειγμα του defacer:

 

Eιδικά στην περίπτωση που μιλάμε για "compilation σε δύο πράξεις" (source ==[compiler]==> bytecode ==[jitter]==> native) νομίζω μπορεί κανείς να το βαφτίσει όπως θέλει.

...περιγράφει ακριβώς αυτό.

Υπάρχει ένας compiler που κάνει τη μετάφραση από Java σε bytecode.

Μετά αναλαμβάνει το JRE να εκτελέσει αυτόν τον κώδικα, σαν interpreter.

Δηλαδή, δεν μεταγλωττίζει το bytecode απ' ευθείας σε γλώσσα μηχανής, ώστε να εκτελεστεί σε τρίτο χρόνο (βλ. παραγωγή executable).

[defacer]

Μετά αναλαμβάνει το JRE να εκτελέσει αυτόν τον κώδικα, σαν interpreter.

Δηλαδή, δεν μεταγλωττίζει το bytecode απ' ευθείας σε γλώσσα μηχανής, ώστε να εκτελεστεί σε τρίτο χρόνο (βλ. παραγωγή executable).

 

Δεν είμαι σίγουρος τι εννοείς πάλι "σαν interpreter". Για .NET που ξέρω με 100% βεβαιότητα, το bytecode γίνεται native από τον jitter on demand και κατόπιν τρέχει on the bare metal (αυτό είναι το παράδειγμα που έδωσα νωρίτερα και επίσης είναι ο λόγος που όταν π.χ. κάνεις cold start μια εφαρμογή WPF κάνει περίπου δυο χρόνια να φορτώσει). Αυτό έχω την ισχυρή εντύπωση πως ισχύει σε κάποιο βαθμό και στη Java (εδώ υπάρχει το tradeoff αργό compilation την πρώτη φορά vs αργή εκτέλεση κάθε μία φορά από το VM αν δε γίνει το compilation) αλλά δεν ξέρω λεπτομέρειες.

 

Contrast με την PHP όπου το αρχικό compilation γίνεται σε bytecode και αυτός με τη σειρά του εκτελείται από τη Zend ένα opcode κάθε φορά.

 

Επιπλέον σε .NET μπορείς αυτό να το κάνεις και AOT για να εκτελεστεί σε τρίτο χρόνο. Και πάλι, δεν ξέρω για Java αλλά δε θα μου έκανε εντύπωση αν υπάρχει η ίδια δυνατότητα (update: φαίνεται πως υπάρχει, αν και όπως διαβάζω το συγκεκριμένο μπλέκεται πάλι το runtime για να κάνει resolve τις κλήσεις στο έτοιμο native image).

[geomagas]

Για .NET που ξέρω με 100% βεβαιότητα, το bytecode γίνεται native από τον jitter on demand και κατόπιν τρέχει on the bare metal

Μα έτσι γίνεται τελικά σε κάθε interpreter: Native κώδικας θα τρέξει στη CPU, δεν μπορεί να είναι κάτι άλλο.

 

Όμως, αυτόν τον κώδικα μπορείς να τον πάρεις εσύ και να τον τρέξεις σε άλλη μηχανή με ίδια cpu αλλά χωρίς .NET εγκατεστημένο; (Δεν είναι ρητορική ερώτηση, πραγματικά δεν ξέρω και ρωτάω)

Και δεν εννοώ να παράγεις ένα standalone exe το οποίο το μόνο που κάνει είναι να πακετάρει τον interpreter και το bytecode (όπως θυμάμαι πως έκανε κάποτε η VB).

 

Μα και μόνο η έννοια του JIT και το on-demand που συνεπάγεται, αποκλείει καθαρό compilation.

 

Contrast με την PHP όπου το αρχικό compilation γίνεται σε bytecode και αυτός με τη σειρά του εκτελείται από τη Zend ένα opcode κάθε φορά.

Ίδια περίπτωση. Παίρνεις κάποιον κώδικα κάποιας ιδεατής μηχανής, και ο interpreter τον μεταφράζει τη στιγμή της εκτέλεσης σε γλώσσα της πραγματικής μηχανής. Αυτή είναι η ειδοποιός διαφορά.

 

Τα JIT, AOT, "ένα opcode τη φορά", "όλα στην αρχή", "σε buckets", "σε chunks" ή οτιδήποτε άλλο, είναι απλά τεχνικές βελτιστοποίησης.

[defacer]

Μα έτσι γίνεται τελικά σε κάθε interpreter: Native κώδικας θα τρέξει στη CPU, δεν μπορεί να είναι κάτι άλλο.

 

Η διαφορά είναι ότι όταν εκτελούνται opcodes πάνω σε VM τότε αυτό ξέρει ακριβώς ποιό είναι το state της εφαρμογής ("αυτή τη στιγμή είμαστε στη μέση της εκτέλεσης μιας function foo και υπάρχει μια local μεταβλητή bar με τιμή 13") ενώ αν έχεις κάνει JIT σε native τότε το runtime δεν έχει ιδέα. Αυτό συν ό,τι συνεπάγεται είναι το contrast που λέω.

 

Όμως, αυτόν τον κώδικα μπορείς να τον πάρεις εσύ και να τον τρέξεις σε άλλη μηχανή με ίδια cpu αλλά χωρίς .NET εγκατεστημένο; (Δεν είναι ρητορική ερώτηση, πραγματικά δεν ξέρω και ρωτάω)

Και δεν εννοώ να παράγεις ένα standalone exe το οποίο το μόνο που κάνει είναι να πακετάρει τον interpreter και το bytecode (όπως θυμάμαι πως έκανε κάποτε η VB).

(θα το πω πιο λεπτομερώς απ' ότι χρειάζεται για να είναι πιο προσβάσιμο σε τρίτους)

 

Σκέψου ότι ο κώδικας αυτός (που παράγει ο jitter) είναι σαν το object output ενός C compiler. Κανονικά machine code δηλαδή που μπορεί να τρέξει σε οποιοδήποτε μηχάνημα της αρχιτεκτονικής. Όταν όμως έχεις πολλά object files και θέλεις από αυτά να κάνεις μια standalone εφαρμογή πρέπει κάποιος (linker) να κάνει τη σχετική κοπτοραπτική ούτως ώστε τα calls από το ένα object file να καταλήξουν να εκτελούν κώδικα που βρίσκεται σε άλλο object file.

 

Αντίστοιχα με το παραπάνω, εργαλεία του στυλ ngen κάνουν compile assemblies σε native code. Παρόλα αυτά, τα cross-assembly calls (και κάποια άλλα πράγματα συγκεκριμένα στο .NET) πρέπει κάποιος να τα κάνει σωστά resolve. Αυτός ο κάποιος είναι το runtime το οποίο πρέπει όντως να υπάρχει στο σύστημα.

 

Υπάρχει όμως και η δυνατότητα (στο link του Mono που έδωσα παραπάνω δες το section "Full AOT") να κάνεις (σχεδόν) τα πάντα resolve από πριν και να μείνεις με ένα εκτελέσιμο που δεν έχει dependency σε τίποτα. Αυτό είναι περίπου το αντίστοιχο του να κάνεις statically link τα πάντα όλα μέσα στο εκτελέσιμο.

 

Οπότε η απάντηση στην ερώτησή σου είναι "ναι, αλλά με κάποιους περιορισμούς". Το site της Xamarin που λέει φάτσα κάρτα "Create Native iOS, Android, Mac and Windows apps in C#"? Έτσι το κάνουν να τρέξει σε iOS (προσοχή εκεί που λέει ".NET framework is included" -- εννοεί τη BCL, όχι το CLR).

 

Μα και μόνο η έννοια του JIT και το on-demand που συνεπάγεται, αποκλείει καθαρό compilation.

Αυτό δεν ισχύει (δες παραπάνω) αλλά επιπλέον δεν καταλαβαίνω τη λογική. Αντί να κάνεις JIT τα κάνεις όλα από πριν, ποιό είναι το πρόβλημα;

 

Ίδια περίπτωση. Παίρνεις κάποιον κώδικα κάποιας ιδεατής μηχανής, και ο interpreter τον μεταφράζει τη στιγμή της εκτέλεσης σε γλώσσα της πραγματικής μηχανής. Αυτή είναι η ειδοποιός διαφορά.

 

Τα JIT, AOT, "ένα opcode τη φορά", "όλα στην αρχή", "σε buckets", "σε chunks" ή οτιδήποτε άλλο, είναι απλά τεχνικές βελτιστοποίησης.

Εδώ τουλάχιστον σε καταλαβαίνω.

[geomagas]

Μάλλον το έκανες υπερβολικά λεπτομερές, και "χάθηκα"...

 

Η ερώτησή μου είναι απλή. Έστω ότι γράφω ένα κομμάτι κώδικα σε C#. Και μετά κάνω compile.

 

Αυτό που θα πάρω είναι ένα εκτελέσιμο που δεν θα έχει πλέον την παραμικρή σχέση ούτε με την αρχική γλώσσα, ούτε με κανενός είδους bytecode ή VM, ούτε θα εξαρτάται από οτιδήποτε προσομοιάζει σε runtime, ακόμα και embedded στο exe;

 

Αυτό ρωτάω.

[defacer]

Μάλλον το έκανες υπερβολικά λεπτομερές, και "χάθηκα"...

 

Η ερώτησή μου είναι απλή. Έστω ότι γράφω ένα κομμάτι κώδικα σε C#. Και μετά κάνω compile.

 

Αυτό που θα πάρω είναι ένα εκτελέσιμο που δεν θα έχει πλέον την παραμικρή σχέση ούτε με την αρχική γλώσσα, ούτε με κανενός είδους bytecode ή VM, ούτε θα εξαρτάται από οτιδήποτε προσομοιάζει σε runtime, ακόμα και embedded στο exe;

 

Αυτό ρωτάω.

 

Ξέχασες να ξεκαθαρίσεις με τι ακριβώς θα κάνεις compile.

 

Αν εννοείς με τον csc τότε το ξέρεις ήδη πως η απάντηση είναι όχι, οπότε δεν καταλαβαίνω το νόημα της ερώτησης. Με έβαλες σε πειρασμό να σου αντιστρέψω την ερώτηση ρωτώντας αντίστοιχα για ένα C compiler και όταν μου απαντούσες "ναι" να σου πω "πριτς, ξέχασα να σου πω ότι έχεις κάνει dynamic link τη C runtime library".

 

Από αυτά που έγραψα νωρίτερα τι δεν κατάλαβες;

[geomagas]

 

Ξέχασες να ξεκαθαρίσεις με τι ακριβώς θα κάνεις compile.

 

Αν εννοείς με τον csc τότε το ξέρεις ήδη πως η απάντηση είναι όχι, οπότε δεν καταλαβαίνω το νόημα της ερώτησης.

Ok, πήρα την απάντησή μου.

 

Με έβαλες σε πειρασμό να σου αντιστρέψω την ερώτηση ρωτώντας αντίστοιχα για ένα C compiler και όταν μου απαντούσες "ναι" να σου πω "πριτς, ξέχασα να σου πω ότι έχεις κάνει dynamic link τη C runtime library".

Άσχετο. Άν και εύκολα συγχέεται...

Από αυτά που έγραψα νωρίτερα τι δεν κατάλαβες;

Δεν είπα ότι δεν κατάλαβα. Είπα ότι δεν μου ήταν ξεκάθαρο ποια ήταν η απάντηση στην ερώτησή μου.

[defacer]

Άσχετο. Άν και εύκολα συγχέεται...

 

Άσχετο με το δικό σου ορισμό της σχετικότητας, τον οποίο δε μας είπες. Με το δικό μου ορισμό ο οποίος είναι "απαραίτητο dependency που πρέπει να υπάρχει στο target σύστημα αλλιώς η εφαρμογή σου δε μπορεί να τρέξει" είναι σχετικότατο.