20 Января 1999

Давным-давно, когда написание простого компилятора еще не считалось задачей на вечер для приличного студента IT-шника, а написание оптимизирующего компилятора было под силу лишь монстрам, была сформулирована одна простая идея. Если мы имеем M языков программирования и N разных процессоров, то чтобы писать на всем подо все, нужно M*N отдельных компиляторов. Что, согласитесь, не фонтан. Посему было предложено создать промежуточный язык, и выполнять трансляцию в две фазы. Сначала из входного языка в промежуточный, потом из него - в код нужного процессора. В результате для покрытия всех M*N сочетаний нужно всего лишь M+N компиляторов (модулей, точнее).

Результатом проработки этой идеи стала схема M+1+N - M парсеров, разбирающих конструкции входного языка и конвертирующих их в стандартную внутреннюю форму, машинно- и языконезависимый оптимизатор, который выполняет над внутренним представлением кода стандартные преобразования, такие, как вынесение инвариантов из сложных выражений, поиск и сведение воедино одинаковых фрагментов в вычислениях и т.п., и N кодогенераторов, которые выполняют машинно-зависимые оптимизации и генерируют код под тот или иной процессор.

Написание такой системы компиляторов - задача простая только на первый взгляд. То есть все просто, если входные языки одноплановы - фотран, бейсик и алгол, к примеру :-).

Если же языки существенно отличаются, то проблем возникает море. Начать хоть с того же управления памятью. Одни языки кидают все на плечи программиста (new/delete в C++), другие берут все на себя (сборка мусора в Java), третьи тоже предлагают сборку мусора, но иначе... Все механизмы нужно реализовать, но зато, реализовав хоть раз, можно уже использовать многократно.

У Новосибирской компании по имени XDS, которая занимается как раз компиляторами, с   поддержкой многих языков и платформ по схеме M+1+N все отлично, и уж много лет. Фирменная линейка компиляторов от XDS знает пять входных языков (основные - Модула -2 и Оберон-2) и умеет генерировать код под несколько процессоров (Intel, PPC,  Motorola, VAX) плюс выдавать результат на... обычном Си, что позволяет работать на всех поддерживаемых входных языках со всеми платформами, для которых есть хоть Си-компилятор. А для каких платформ, скажите, его нет.

Плюс к этому - библиотеки, отладочные средства, инструментарий - в общем, изрядный набор. Одно только во всем этом, как мне представляется, было плохо. Оберон - язык, конечно, интересный. Но, как бы это сказать, не самый популярный нынче. Что сдерживало спрос на продукты от XDS. Не знаю, это ли явилось причиной следующего шага или просто академический интерес сыграл, но компания озадачилась вопросом - а нельзя ли к комплекту входных языков прибавить.. Java?

Причин для того, чтобы задаться этим вопросом, несколько. Во-первых, если уж многоязыковая система компиляции существует, почему бы не расширить ее применимость, добавив в набор еще один, весьма популярный язык. Во-вторых, что касается самой Явы, то быстродействие программ на ней - одна из самых актуальных задач. Рожденная как язык интерпретируемый, Ява относительно нетороплива. С этим неизбежным злом приходится мириться в Интернете, где процессор, на котором работает броузер, может быть каким угодно и нужно, чтобы один и тот же аплет заработал везде и всюду.

Если же мы пишем на Яве приложение то, как правило, целевой процессор известен, а если и нет, то будут, как правило, известен к концу разработки. А значит - нет причин не заняться ява-компилятором. Не хаком типа JIT, который кое-как компилирует код на ходу, а полным, понимающим толк в оптимизации инструментом.

Задача эта не так проста, как может показаться - есть у Java свои тонкости, требующие массы усилий при реализации компилятора.

Но, как догадывается читатель, XDS эти усилия уже приложила, и сегодня объявлен прототип (NB - пока не окончательный продукт) Ява-компилятора от XDS, и если вам это интересно - его можно скачать на пробу вот тут.

Я же хочу поздравить XDS с новой победой и пожелать им, как и всем нашим программистам удачи. В том числе и коммерческой.

Поздравление со Старым Новым Годом от компании Парагон: "На некоторое время компания устанавливает стоимость своего продукта PiLoc-III в НОЛЬ долларов. Каждый владелец устройства Palm-III, равно как и любой дилер, занимающийся продажей таких устройств сможет бесплатно получить неограниченное количество копий русификатора PiLoc-III. Для этого надо просто отправить уникальный номер flash-ID устройства Palm-III на адрес FreePiLoc3@paragon.ru. PiLoc-III - это первая в России система полной русификации для устройств Palm-III. До начала акции стоимость продукта составляла $45."

Правда, приуроченность этого события к Старому Новому Году вызывает некоторые сомнения, особенно после сравнения дат двух пресс-релизов. :-) Вышеприведенный датирован 12-м января. А нижеследующий - 11-м.

"Компания МакЦентр объявляет о подведении итогов конкурса на разработку русификатора для
карманного компьютера Palm III компании 3Com. [...] Конкурсная комиссия имеет честь сообщить, что победителем в разряде "русификатор для Palm III" признана программа PaPiRus компании Физтех-софт. [...] Компания МакЦентр поздравляет победителя конкурса - компанию Физтех-софт, и объявляет, что в соответствии с подписанным договором компания Физтех-софт предоставляет МакЦентру эксклюзивное право на распространение русификатора PaPiRus. Начиная с 11 января 1999 г. все устройства Palm III, продаваемые по каналам МакЦентра, будут комплектоваться русификатором PaPiRus."

Таким образом поздравления Парагона со Старым Новым Годом, видимо, адресованы, в основном, Физтех-софту. :-)

Музыкальные сборники - диски с MPEG-файлами, представляющими собой полную коллекцию дисков той или иной группы - появились на московских пиратских рынках довольно давно. Настолько, что умудрились даже составить приличную (в плане объема:-) конкуренцию дискам обычным и вызвать на себя огонь критики, обусловленный не всегда приемлемым качеством звука. На MPEG-дисках выходили Queen и Beatles, БГ и Pink Floyd, и все это требовало довольно высокого качества звука. Жадность же изготовителя (точнее, желание запихнуть всю дискографию именно на один диск) приводила к повышенному коэффициенту компрессии MPEG, и, как следствие, к пониженному качеству звучания. Порой вплоть до среза высоких частот, что уж совсем никуда не годится.

Обложка диска

Вчера же я купил на Митино диск, которому, казалось бы, все это не грозит. Диск этот - с детскими песенками. Из мультиков и детских фильмов плюс (видимо, авторы любят эту группу) с пластинок Дюны. Исключительная классика советской детской песни - хит на хите. Причем, как вы понимаете, качество оригиналов, зачастую, такое, что никаким MPEG-ом уже не задушишь, не убьешь - убивать просто нечего. Высоких там уже нет, динамики там тоже уже нет, шум там уже давно и надолго, в общем, "все уже украдено до нас". Записать плохой диск с таким материалом невозможно! Портить категорически нечего.

Да?

Фиг.

Умеючи, оказывается, можно изгадить все, что угодно. :-) Диск записан без нормирования... уровня сигнала. Песни просто разные по громкости, причем сильно. То есть одну еле слышно, другая сотрясает стены.

И тем не менее, за содержание четыре балла я бы этому диску выставил - сама идея хороша. Собрать все эти песни - нелегкое дело, а иметь в фонотеке джентльменский комплект для своего ребенка - мило дело. Кстати, вот список песен на диске (gif).

За техническое исполнение - три балла. Как я уже говорил, минимальных усилий по причесыванию звука предпринято не было, плюс софт, поставляемый с диском не живет под NT. Три, а не два - потому, что хоть сами песни лежат в виде просто mpeg-файлов, и потому их можно слушать чем угодно. Иные извращенцы делают свои форматы файлов, и когда "родная" программа оказывается неспособна работать, пользователь остается с носом. Я же остался с WinAmp-ом, что совсем не так уж плохо.

Вообще, закрытие линии Win98 грозит пользовательскому составу нашей планеты изрядными проблемами. Под NT (Win2000) не живет, живет криво, живет через раз, живет только при выстраивании планет солнечной системы в одну линию, пожалуй, с половина софта под Windows. А другая для того, чтобы жила требует пинания изрядного. Вчера прикупил простенький сканер-планшетник - случаются порой потребности отOCRить что-либо, так вот, чтобы иметь такую возможность. Ну купил и купил. Сунул в одну машину - не идет. Софт запускается, но сканировать не хочет. Я теперь умный, я знаю, что самый простой способ победить что-либо под Windows - это не искать причину проблемы. Нет у нее причины. Нужно просто сунуть в другую машину, там оно, скорее всего, пойдет. Ну, я сунул в другую машину. Оно установилось, перезагрузилось и... сразу упало. Я еще раз перезагрузился - опять упало. Дай, думаю, на драйвер гляну. Гляжу - а в каталоге драйвера валяется файл по имени что-то.vxd. Вот ведь гад, а? Он даже не нашел нужным при инсталляции проверить, что это не 95 и не 98, и сказать - мол, я сделан на VXD и под NT жить не буду.

Подарок номер два состоял в том, что сайт производителя был... закрыт на переоформление. То есть им там приспичило сначала убить старый сайт, а потом начать делать новый. Вместо того, чтобы сделать и одним движением руки незаметно для пользователя подменить один другим.

Ну, драйвер я нашел на сайте московской фирмы, торгующей этими сканерами. Но непрофессионализма наелся - по самое не хочу. Мало того, буду есть его теперь при каждом сканировании. Сканер работает через принтерный порт, причем, поскольку про прерывания программисты, писавшие его софт, видимо, не знают, при сканировании он грузит PII 300 на 100%. А поскольку в Микрософте писать шедулеры так и не умеют, NT при одном процессе, жрущем 100% процессора, встает колом и перестает реагировать на клавиатуру.

Отчасти, правда, сам во всем виноват. Нужно было брать USB-шный сканер. :-) Так не предложили, вороги. :-(