Czy smali jest assemblerem?

Odpowiedz Nowy wątek
2013-04-14 17:13
0

Na oficjalnej stronie, https://code.google.com/p/smali/ , Smali jest zdefiniowany jako

assembler/disassembler for the dex format used by dalvik, Android's Java VM implementation

Także Wiktionary definiuje go jako

assembler (compiler for assembly language)

Dodatkowo wydaje się on mniej więcej pasować do definicji assemblera:
https://en.wikipedia.org/wiki[...]anguage#High-level_assemblers
Mnie także wydaje się że można uznać go za rodzaj assemblera wyższego poziomu, bo przeznaczonego dla maszyny wirtualnej. Znajomi twierdzą jednak że jest to terminologia niepoprawna.

To jest po prostu bytecode dla dalvika

Jakie jest wasze zdanie na ten temat (i czy ten dział jest odpowiedni? xP)?

edytowany 2x, ostatnio: Avallach, 2013-04-14 18:06

Pozostało 580 znaków

2013-04-14 18:16
1

A czy koledzy wiedzą np o:

  • emulowaniu x86 np z użyciem DosBoxa,
  • procesorach Transmeta i oprogramowaniu tłumaczącemu kod x86 na kod zrozumiały przez te procesory,
  • Jazelle w procesorach ARM, które pozwala na sprzętowe wykonywanie bajtkodu Javowego?
    ?

Jeśli chodzi o opkody typu method to przecież nawet jak się klepie w asmie apkę pod DOSa czy Windowsa to trzeba zakodować też rzeczy inne niż sam kod. W DLL-kach np trzeba zapisać gdzieś gdzie są metody, żeby potem OS mógł przeliczyć adresy przy ładowaniu DLL-ek.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2013-04-14 21:21
0

Niezupełnie o taką odpowiedź mi chodziło (szczerze mówiąc - nie zrozumiałem do końca przekazu), raczej o to który z terminów poprawnie określa naturę Smali: assembler, czy kod bajtowy. Ja dalej jestem przekonany że assembler, czyli czytelna dla człowieka reprezentacja kodu używanego przez maszynę - w tym przypadku właśnie kodu bajtowego wirtualnej maszyny Dalvika (a sam tym kodem nie jest).

W przypadku maszyn fizycznych assembler jest reprezentacją kodu maszynowego i taki zwykle ma się na myśli, ale definicja się do takich nie ogranicza. JavaVM też ma swój assembler, reprezentujący jej kod bajtowy: http://tinf2.vub.ac.be/~dverm[...]ses/compilers/javaa/jasm.html (na pierwszy rzut oka całkiem zresztą podobny do Smali!). Szybko szukając znalazłem też assembler dla kodu bajtowego Flasha: http://sourceforge.net/projects/flasm/
Nie wykraczają one poza definicję wysokopoziomowych assemblerów: https://en.wikipedia.org/wiki[...]anguage#High-level_assemblers
Autorzy Smali, tak jak tych wymienionych powyżej, wyraźnie określają go jako assembler (a chyba się jednak znają na rzeczy): https://code.google.com/p/smali/
http://stackoverflow.com/ques[...]n-assembly-code-and-bytecode/ - najlepsza odpowiedź mówi o tym że kody bajtowe maszyn wirtualnych też mogą mieć swoje assemblery i że chociaż zwykle odnosi się ten termin do maszyn fizycznych z kodem maszynowym, to właściwa definicja jest szersza.

Błędne przekonanie że Smali assemblerem nie jest mogłoby się brać z tego że w porównaniu z assemblerami maszyn fizycznych, będących odwzorowaniem kodu maszynowego, zawiera instrukcje dość wysokiego poziomu. Ale to nie złożoność jest kryterium określającym czy dany język jest assemblerem czy nie, tylko to czy jest czytelną dla człowieka reprezentacją kodu używanego przez daną maszynę. Smali spełnia ten warunek.

Poprawcie mnie jeśli się mylę.

Pozostało 580 znaków

2013-04-14 22:57
0

Moim zdaniem dobrze myślisz.

Różnicą między ISA np Javy a x86 jest to, że ISA Javy zostało zaprojektowane tak by można było łatwo i jednoznacznie bajtkod Javowy zdisasemblować i zanalizować (JIT i Jazelle doszły na długo po pierwszej wersji Javy), a ISA x86 zostało zaprojektowane po to, by kod asemblerowy był czytelny (co dzisiaj nie ma prawie żadnego znaczenia) oraz by można było go zrealizować przy małej liczbie tranzystorów oraz by skompilowany kod był w miarę kompaktowy (to dzisiaj mocno wadzi, bo instrukcje są ciężkie do zdekodowania oraz równoległego wykonywania).

Na niskim poziomie wygląda to tak, że np o ile w x86 można sobie działać na wskaźnikach jak na zwykłych liczbach, to w Javie wskaźnik jest wyabstrahowany - nie da się odczytać jego wartości, jedyne co można to dostać się do obiektu na który wskazuje oraz ewentualnie porównać dwa wskaźniki pod kątem równości.
Natomiast gdyby do JARa dorzucić informację, która reprezentuje jakieś tam mapowanie identyfikatorów na offsety w JARze (JVM robi coś w ten deseń przy ładowaniu JARa tak czy siak) to można by zrobić procesor wykonujący kod Javowy tak samo jak procesor x86 wykonuje kod pod niego napisany. Intel zaprojektował i produkował kiedyś procesor, który sprzętowo wykonywał odśmiecanie i inne formy zarządzania, link tutaj: http://pl.wikipedia.org/wiki/IAPX_432


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2013-04-14 22:58

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0