ACPU - новая платформа. Разработка для iOS под Linux.

Основные преимущества: разработку можно делать на планшете

Зачем это делать? Это ведь наверняка намного неудобнее, чем разработка на полноценности компьютере.

кроссплатформенное

Понятно

Мгновенная компиляция и отображение результата.

У меня в связке макбук-айфон тоже практически мгновенное отображение результата. По крайней мерк не было большого желания ускорить его.

Или имеется в виду возможность менять код работающего приложения? Если да, то принимается.

Еще интересно — насколько оно хуже obj c по производительности и просто ли писать часть программы на obj c?

сейчас не многие используют планшеты

Привет из двадцатого века?

r0 - регистр, переменная тип float. аналог регистра проца. на каждый блок выполнения выделено определенное к-во регистров. почему ограниченное к-во регистров

Мдя. Даже C, похоже, будет повыше уровнем, чем это говнище.

Зачем это делать? Это ведь наверняка намного неудобнее, чем разработка на полноценности компьютере.

Планшеты давно по производительности тот же pc, но с иным форм-фактором. При желании можно подключить дисплей, клаву и мышь. Сейчас стирается последняя грань между pc и планшетами, форм-фактор становится универсальным - все консоль. Intel это официально заявило, есть статья на хабре почему они сделали мобильные устройства основным направлением, m$ тормозит еще, но тоже в это вкладывает не мало. Планшет уже выигрывает у pc по некотороым параметрам (потребление, touch, размеры), проблем в железе нет. Есть проблемы в софте, это 2я прога для полноценной разработки ipad, ситуация такая же, как и с играми, когда их было 10 штук. Не на чем разрабатывать, было бы на чем, уже было бы много положительных отзывов (см. форум codea и отзывы на appstore). Еще пошла тенденция к удаленному обучению, куда вкладывает MIT и билли, они уже поддержали codea, поскольку обучение на планшетах самое то.

У меня в связке макбук-айфон тоже практически мгновенное отображение результата. По крайней мерк не было большого желания ускорить его.

Я работаю с большими проектами, там 200 классов (400 файлов), 20 либ, бинарники по 170MB, XCode при этом начинают вылазить всякие чудеса, вроде 100% CPU когда ему вздумается, падения и инсталляция занимать начинает занимать минуты. Для разработки анимаций/игр это вообще никак, потому и Titanium и PhoneGap успешно проинвестированы и Adobe AIR вкладывает уже который год (а оно как раз на анимации заточено). Много ограничений и ньюансов, что в лучшем случае забирает время=деньги, а когда и до конфликтов доводит. У меня старые версии XCode вообще не могли большие исходники распарсить - все падало в code dump. Сейчас падения когда отлаживаешь gl, оно все монстрообразно и будет еще больше. Посмотрите на частоту апдейтов XCode, это не из-за наворотов, это из-за багфиксов в основном видимо, очень сильно отличается работа, хотя ничего особо нового. Мне приходится держать несколько версий XCode из-за этого, лишних 7 гигов на скромном ssd это не гут. Конечно для простых проектов подойдет и многих устраивает, это у меня так выходит, что 2 xcode 5 виртуалок и еще что, чтобы иметь полную свободу действий и не отвлекаться на недоработки. Кому-то одного устройства и одной системы достаточно для его задач.

Или имеется в виду возможность менять код работающего приложения?

Да, горячая замена кода в работающем приложении, как в erlang

Еще интересно — насколько оно хуже obj c по производительности и просто ли писать часть программы на obj c?

Есть 2 режима выполнения, в виртуальной среде на основе exprtk (смотрите бенчмарки на их сайте, достаточно шустро, хоть и индианец делал) и экспорт в C, который потом компилируется стандартными средствами - производительность максимальная со всеми оптимизациями clang. obj c сам достаточно тормознутый из-за runtime, ближе к JS, потому виртуальную машину имеет смысл сравнивать с C/C++. Масштабных тестов не проводилось, но оверхед не большой, в 10 раз медленнее C в таком loop-тесте:
C:
volatile int i;
for(i=0;i<30000;i++);
ACPUL:
r0:=30000;
while(r0){r0-=1;};
* iPad 2:
* O0 O3
* Exprtk - 0.046944 0.008096
* Native - 0.002739 0.000975
* Taste - 0.04 0.010931

Taste - это stack vm из примеров coco/r, она примитивна, для сравнения

Пока в первой версии производительность устраивает, потом можно будет все оптимизировать (запасы есть) и заменить exprtk на что-то более шустрое.

просто ли писать часть программы на obj c?

Да, просто.

Код для Objective-C:
- (void)registerDispatcher:(NSRange)range delegate:(id)delegate;

[acpu registerDispatcher:NSMakeRange(10000, 1) delegate:self];

- (float)ioWrite:(VVEffectsNode *)node address:(int)address p0:(float)p0 p1:(float)p1 p2:(float)p2 p3:(float)p3;
{
NSLog(@«%i», p0);
return 54321;
}

Код для ACPUL:
r0:=io(10000, 12345, 0,0,0);
watch(r0);

В консоли выведется 12345 и 54321.

от такого страшного вида можно уйти, обернув через декларации ACPUL в отдельную библиотеку:
my.objective.c.call.delegate r0:=io(10000, 12345, 0,0,0);
my.objective.c.watch.result watch(r0);

итого имеем на уровне пользователя:
my.objective.c.call.delegate();
my.objective.c.watch.result();

все еще длинно, может не влезть в и без того малый экран ipad. создадим еще библиотеку с короткими названиями.

my.delegate my.objective.c.call.delegate();
my.result.watch my.objective.c.watch.result();

my.d my.deleage;
my.w.d my.result.watch;

итого код, который будет многократно использоваться укорочен:
my.d();
my.w.d();

Кластерная архитектура расчитана на не большие программы, чтобы избежать пересечения коротких имен. один файл 100 строк, этого хватает для большинства типичных задач (не забываем про ограничение памяти в 64МБ для процесса на ipad).

Также легко подключается и на любом другом языке, C/C++, Java, AS3, JS... Не надо учить замудренные API, что угодно можно связать с чем угодно. Это в первую очередь инструмент прототипирования, чтобы сразу проверить и получить рабочий ощутимый результат. Правильные имена и супер-C++-Java-код потом можно написать (или сразу экспортить ACPUL в нужный язык, если решение полностью устраивает).

Вы наверно никогда не слышали об AML, вот то унылое гэ. И в свете перспектив закрытости UEFI при поддержке m$ вскоре его прийдется учить любому желающему ставить линукс на _любое_ железо.

Регистры выбраны идеологически. Нет разницы между 'int i' и 'i r0'. Второй вариант короче и логичнее в данной системе координат.

Ссылки на *deb чтобы поставить IDE ос всеми плюшками за один раз, не вижу

Оно еще не open-source. Как раз стоит вопрос выяснить все +/-?

Переноси, добавил финальный код, который нужно расширять и улучшать. https://github.com/d08ble/acpu/tree/master/compiler

Вы наверно никогда не слышали об AML, вот то унылое гэ.

О каком именно? Algebraic Modeling Language?

И в свете перспектив закрытости UEFI при поддержке m$ вскоре его прийдется учить любому желающему ставить линукс на _любое_ железо.

Скобочная структура не ясна. Имеется в виду «каким бы ни было железо, желающему ставить на него линух придётся учить AML»? Это, разумеется, неверно. Дистрибутивы типа убунты не убить. Или имеется в виду «тому, кто хочет ставить линух на всё, что есть на свете, придётся учить AML»? Опять-таки неверно, ему лучше сразу убиться об стену, ибо бывают-таки железки, на которые линух не поставишь.

Регистры выбраны идеологически.

Я уже понял. Такое убожество можно выбрать только идеологически.

Нет разницы между 'int i' и 'i r0'.

Есть, конечно. Регистры - это глобальные переменные, то есть, по сути, антипаттерн.

Вы наверно никогда не слышали об AML, вот то унылое гэ.

О каком именно? Algebraic Modeling Language?

Упоминание уродства, AML и UEFI в одном контексте как бы намекает на ACPI Machine Language.

Нет разницы между 'int i' и 'i r0'.

Есть, конечно. Регистры - это глобальные переменные

Вроде русским языком сказано: «глобальные для среды u0-u32, локальные функции r0-16 и локальные блока b0-b32».

Упоминание уродства, AML и UEFI в одном контексте как бы намекает на ACPI Machine Language

Не мешай троллить.

Вроде русским языком сказано: «глобальные для среды u0-u32, локальные функции r0-16 и локальные блока b0-b32».

Пропустил, согласен.

Правда, тогда вообще непонятно, зачем ограничивать количество и возможные типы данных.

Правда, тогда вообще непонятно, зачем ограничивать количество и возможные типы данных.

float - для инструкций, логики и математики, хорошо оптимизируется на Cortex A9 (отдельный высокопроизводительный конвеер, медиа-процессор все же)
object - любой объект, в том числе и тип. понятие объект в данной системе координат подразумевает что угодно, в том числе и тип данных, например:

a:=newObject(int, 123);
b:=newObject(date, 16, 05, 2013);

или просто:

a:=int(123);
b:=date(16, 05, 2013);

Ограничений по типу данных нет. Напомню, основная идея, чтобы язык и система прогрессировала благодяря свободному обмену кода, если большинство разумных людей скажет, что там нужен тип int, тогда оно оформится в форме компилятора и api, нужна конструкция enum или иная, тоже самое. ACPUL это конструктор, на котором можно создать что угодно, это относится и к грамматике языка. Например для поддержки JSON в IDE можно создавать LL(1) парсеры в формате ATG (coco/r), которые потом транслируются в ACPUL и в теории ACPUL должен когда-нибудь скомпилировать сам себя. Производительность при этом страдает не сильно, для парсинга JSON фактически тоже, что и на C делать.

зачем ограничивать количество

Из практики, считайте такие граничные условия задачи обусловлены аксиомой.

Расширяем познания: Язык DOU схож по идеологии упрощения написания программ и тоже есть идея IO для связи. В отличии от DOU, в ACPUL отсутсвует такое количество сложных конструкций, потому порог вхождения ниже.

Link: http://daovm.net/

UP: Начался процесс над трансляцией компилятора в JS посредством https://github.com/kripken/emscripten/wiki#demos , acpul.org пилится во втором приоритете.