Имхо, бинарик генерированный fpc будет чуть больше аналогичного gcc, но его запросто можно пере компилировать под i386(linux) и даже возможно windows
Да пусть будет больше. Меня скорость волнует.
Медиаконвертер для Android Главный тормоз на Android это Java
Медиаконвертеров и так как грязи. Я по привычке графикой собираюсь заниматься. Софтовой и аппаратной.
Приличная GUI-библиотека у меня даже есть. Не зависит от того, кто и как будет её контролы рисовать, но написана на Паскале.
Вот и думаю.
Насчет тормозов Java и особенно Dalvik не уверен. Java давно обгоняет Delphi (а значит и FPC) по производительности на i386. И даже Javascript обгоняет, что вообще уже ни в какие ворота не лезет.
Самое печальное, что перспектив изменения этой ситуации никаких нет. Embarcadero тут проблемы вообще не видит. У команды FPC был замечательный шанс прикрутить поддержку LLVM, но, похоже, это никому не нужно. Хотя это решило бы проблему.
Для PC это еще ладно, там все равно в основном вызовы API, да и мощи достаточно, но на Андроиде это уже неприемлимо. Больно разные девайсы.
Как известно в Android используется эмулятор регистровой байт машины. Все (практически) пользовательские приложения написаны на Java и транслированы в данный байт-код. FPC не умеет генерировать данный байт-код.
А еще вода мокрая, ага.
FPC генерирует код для ARM везде одинаково и он не зависит от типа ОС.
Мой вопрос, собственно, и состоял в том, как он его генерирует?
Как для i386, или, может быть, более эффективный? Все таки ARM вроде более прямая вещь, нежели i386 и вменяемый кодогенератор написать для ARM должно быть проще.