yes 7 25 марта, 2010 Опубликовано 25 марта, 2010 · Жалоба я подробно не смотрел и не специалист в теме, интересует доки, объяснения и т.п., ну а прежде всего оценку затрат что-то подобное есть Zylin ZPU - но сам процессор не такой как надо, а сорсы md и т.п. я не осилил ------------- также интересно, что предпочесть LLVM (c GCC frontend) или GCC? порт более легких компиляторов не интересен, так как нужно полную поддержку С++ ------------- MISC интересует из-за возможности сократить объем кода, но насколько это получится, без компилятора трудно определить... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 25 марта, 2010 Опубликовано 25 марта, 2010 · Жалоба Сначала к бородатому дядьке, а затрат должно быть много. Опыт написания для TMS320-C6000. Результатом не спешат делиться :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 26 марта, 2010 Опубликовано 26 марта, 2010 · Жалоба Сначала к бородатому дядьке, а затрат должно быть много. Опыт написания для TMS320-C6000. Результатом не спешат делиться :) про дядьку знаю - btw: сильно удивился, когда не смог найти книжку в открытом доступе и пришлось качать с торентов, думал даже, что пожадничал дядька, несмотря на свои принципы - спасибо за ссылку но мне (прошу не пинать если что) гораздо больше понравился llvm, в котором промежуточные результаты даются в виде нормального "превдоассемблера", а не мутные RTL деревья, которые в виде файла то и представить нельзя (не рекомендуется, фор дебаг онли и т.п.) я не нашел в доках (и gcc, и llvm) объяснения как вообще влияет MD на оптимизацию (в случае gcc на финальный RTL), ну то есть в gcc это влияние (количество регистров их свойства и т.п., время исполнения команды ...) есть на каких-то шагах оптимизации все примеры ABI похожи друг на друга - RISC процы (даже C6000 можно подогнать), а процессор со стековыми операциями??? может какой-то пинок от гуру прочистит восприятие :) -------------- в LLVM я вообще не понял - оказывает ли таргет какое-то влияние на оптимизацию или свойства таргета применяются только на этапе кодогенерации.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 26 марта, 2010 Опубликовано 26 марта, 2010 · Жалоба я не нашел в доках (и gcc, и llvm) объяснения как вообще влияет MD на оптимизацию (в случае gcc на финальный RTL)... ненашли потому что никак не влияют, -M предназначена для организации зависимостей и к кодогенерации неотоносится бородатого дядьку к руководству я всетаки не рекомендовал - силно старый. инфраструктура внутренностей то поменялась, оптимизатор в рамках только 4 версии писали-переписывали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 29 марта, 2010 Опубликовано 29 марта, 2010 · Жалоба ненашли потому что никак не влияют, -M предназначена для организации зависимостей и к кодогенерации неотоносится бородатого дядьку к руководству я всетаки не рекомендовал - силно старый. инфраструктура внутренностей то поменялась, оптимизатор в рамках только 4 версии писали-переписывали. а что из описания машины влияет на оптимизатор? я так понимаю, что список абстрактных команд (standart pattern) должен быть поддержан весь - ну например ‘umulqihi3’ нужно либо описать в виде инструкции, либо в виде набора инструкций или какого-то С-шного кода, который сгенерит ассемблер для таргета, или же обеспечить библиотечный вызов такой функции - так? а что происходит, если в define_insn для umulqihi3 стоит безусловный FAIL : компилятор сумеет сгенерить "промежуточный" код без использования умножений или так просто нельзя писать md? я так понял, что оптимизация проводится только на уровне подбора операндов для выбраной инструкции (pattern), при этом подразумевается стандартный RISC процессор типа ARM/MIPS - так? upd : большинство шагов оптимизатора типа субэкспрешин, констант пропагэшн, и т.п., которые выполняются при анализе исходного кода я считаю независимым от machine description. собственно если попытаться сформулировать вопрос - где в gcc проходит граница между таргет-индепендент оптимизацией и использованием описания машины (С-макросы, патерны md и т.п.)??? мне бы хотелось понять некоторые общие моменты, которых я не нашел в документации. --------------- про llvm я так понял, что все шаги оптимизатора выполняются для "абстрактной" виртуальной машины и граница между оптимизатором и кодогенератором (если я правильно понимаю этот термин - преобразователем внутреннего представления в таржет ассемблер) четко определена. то есть кодогенератор для любого таржета получает одинаковый код в "llvm ассемблере", из которого генерируется код для таржета (при этом алокацией регистров занимается пользовательский кодогенератор) в gcc (как я понимаю) RTL код генерится с учетом параметров таргета и распределение регистров (ну использование их для сохранения временных значений, без выгрузки в память) если так, то потенциально код llvm должен быть хуже gcc, а они утверждают, что бьют gcc по скорости/размеру кода --------------- вобщем я бы склонился в сторону llvm (в худшем случае смогу написать на питоне транслятор из их кода в свой проц), но может я вообще все понял неправильно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 2 апреля, 2010 Опубликовано 2 апреля, 2010 · Жалоба -------------------- для llvm столкнулся с тем, что глючит безбожно (при использовании long long) то есть пока gcc only :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
