Czy smali jest assemblerem?

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/Assembly_language#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)?

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.

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/~dvermeir/courses/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/Assembly_language#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/questions/1782415/what-is-the-difference-between-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ę.

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

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