(Untitled)

[muchandr]

Какая прелесть. ARM тихой сапой добавил явовские байткоды в качестве еще одной ISA. (у них уже и так было две) Поскольку ARM просто везде, можно с уверенностью говорить, что никакой Явовской виртуальной машины вне пределов совсем "взрослых" писюков и рабочих станций уже нет - нелепая архитектура явовской машины канонизорована "в железе"! Фу

Comments

[potan]

Виртовцы сжимали AST Оберона. На мой взгляд - фигня вышла.
JITу сложные адресации не нужны. Он переводит стековый код в нормальный трехадресный, а потом его компилирует.
Аппаратная Java хороша для систем с маленькой памятью. Каковыми являются все встраиваемые системы :-).

[lnvp]

По-моему вся возня вокруг Оберона - опереточная история. Поздно, глупо, смешно. Если бы Вирт и его единомышленики - в своё время! пока было не поздно! - просекли, что идеологическая борьба за промышленный язык может идти только по линии Паскаль vs. С, можно было бы прокачать Паскаль (ну типа как делал Борланд, но не в частной лавочке, а на уровне стандартов) и не заниматься придумыванием всё новых и новых "лучших Паскалей" (Модула, Модула-2, Оберон, наконец... - пока Вирт их придумывал и по-академически внедрял, поезд давно уехал).

[muchandr]

Совершенно согласен. Помню время, когда Turbo Pascal был самым крутым компилятором на PC вообще. Вирт в целом оказался one trick pony - он почему-то считал, что мир спасет все более анальная типизация. Modula-2 это типа Паскаль, в котором для каждого типа есть cвоя разновидность команды print. Псих. Ошибки, сводящиеся к кривому тайпкасту далеко не самые серьезные.

[lnvp]

Про print в Модуле-2 не помню (всё ж-таки там какой-то оверлоадинг присутствовал хотя бы для встроенных функций), но в ней была приличная - на уровне языка! - система раздельной компиляции, сильный пойнт супротив С. Но называть и продвигать это нужно было как Паскаль 2 :) (в исходном описании Паскаля эта тема, увы, не была раскрыта).

[muchandr]

В смысле модули? Да ну на, к тому времени уже давно придумали make. Просто под DOS он был не шибко применим из-за лимитации строки параметров в COMMAND.COM на 136? шоли символов.

[9000]

Увы, make не меняет ситуацию так, как её меняют хотя бы precompiled headers, и тем более - сравнимо с нормальной декларативной модульностью.

Всё же ряд решений, принятых в своё время в C, оказался источником длительных головных болей: null-terminated strings (любимый источник дыр через stack overflow), headers вместо нормальных модулей, отсутствие явного boolean... Эх.

[muchandr]

Мне null-терминированные строчки не нравятся излишним торможением. Ценой еще большего торможения, stack overflow можно решить нах (см. Tripwire) А зачем явный boolean? Как раз тот факт, что С экспозает его фундаментальную int-о-бразность там и сям позволяет скостить conditional branch. Мне нравиццо...

Я бы в раздел головных болей записал бы скорее фундаментальную склонность к memory aliasing, негуманный синтакс функциональных поинтеров, непонятки с функциями, возвращающими аггрегатные структуры данных и, раз мы уж претендуем на замену ассемблера, синтаксическая невозможность напрямую манипулировать отдельные биты даже на архитектурах, которые такие вещи допускают.

[9000]

Строки со счётчиками решают, как доказывает нам формат MIDI :)

Беда прямого использования int как boolean мне видится в основном в том, что "a = 1" становится логическим выражением, равноправным с "a == 1". В ООП это решается тем, что зовётся какой-нибудь a.toBoolean(), и можно продолжать спокойно писать "if (a) {...}", не напрягаясь про нечаянное "a = 1".

Memory aliasing, я так понимаю, неизбежен и в ассемблере.

Про синтаксис указателей на функции согласен. Туда же type cast, туда же typedef (хотя он не столь ужасен). В общем, хак на хаке. Для себя писали, а вышло публичным.

Отдельными битами можно рулить в структурах, как я помню. Хотя ты, похоже, имел в виду что-то вроде i432 ;)

[muchandr]

Про формат MIDI вообше не в теме, можно подробнее? Турбо Паскаль в нулевом элементе держал счетчик, почему в частности долгое время делал все локальные версии С, включая Турбо

[9000]

В MIDI счётчики в начале "строки" - произвольной длины: если старший бит байта счётчика = 1, то следующий байт тоже составляет счётчик, и т.д. сколько угодно. Эффективно кодируются как короткие строки, так и очень длинные. Были бы турбо-паскалевские строки такими, жизнь на 32- и 64-битных архитектурах у них была бы дольше.

Про ассемблер я ступил: там же нет scope, о котором думает компилятор.

Имелась в виду iAPX 432, у которой, по воспоминаниям из читанной в древности книжки, была адресация даже отдельных бит, поскольку доступ ко всему там тщательно контролировался железом. Пока статья в википедии этого не подтверждает.

Теоретически можно сделать struct с числом bit fields по числу нужных бит, и везде использовать его. Но возникает проблема - надо к нему кастить, надо помнить про порядок бит в памяти, в общем, тоже недодумано.

[muchandr]

Про строки красиво, но даже и не особо нужно. Подавляющее большинство строчек в среднестатическом коде очень короткие. Пусть это был бы некий lognstring, а так хватило бы и байта. С overflow не шибко разгуляешься, плюс в конвенции что строка есть array, начинающийся всегда с индекса 1, есть свои прелести

[9000]

Идея рулезная. Но alignment / padding, боюсь, не исчезнет совсем, поскольку память наверняка будет выдавать сразу много бит за операцию (ибо это часто нужно), и не попадать в размер выборки будет невыгодно.

Почему, кстати, массовый параллелизм для бедных-то? Можно же и "обычный" запрячь, как в GPU, наверное? Сделать юниты достаточно большими и умными, чтобы компилятору не приходилось думать совсем обо всём, на уровне каждого бита переноса. А то будет как с итаниумом (тоже ведь красиво задумывали).

[muchandr]

1. Не согласен. У такой памяти может быть произвольный interleave, а все интерфейсы к оной так и так уверенно продвигаются от параллельных к серийным. Как и все остальное, кроме собственно процессоров.

2. Кстати, а ведь все VLIW трюки будут тоже к такой хрени еще как применимы. Даже лучше, поскольку можно выкинуть оптимизации под заданный размер вектора.

[9000]

А как мы будем передавать N разных адресов для N бит, которые хотим видеть в следующем такте? Вроде вся выгода поставки N "соседних" бит - в параллельной выборке по единому адресу. Как добиться одновременности выборки?

Всячески верю, что можно найти много осмысленных асинхронных 1-битных алгоритмов :) Но чаще нужно много упорядоченных бит сразу (числа там).

[muchandr]

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

Тоже идиология совсем не новая. см. PCI-E например. Хош 1 канал, а хош 16. 16 дороже, но серийная архитектура в основе та же)

[9000]

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

Но смотри: мне нужно 16 разрозненных бит. Мне надо установить 16 адресов, откуда-то их загрузив или вычислив. А если 16 последовательных бит, то достаточно начального адреса и счётчика бит. Тут, мне кажется, зарыта некоторая экономия времени, и не пользоваться ей будет глупо. Т.е. здорово, конечно, иметь возможность грузить совсем независимые биты. Но и дёшево грузить зависимые тоже полезно.

С третьей стороны, если архитектура одноадресная (стековая, например), то вопрос становится нерелевантным: каждая команда грузит столько бит, сколько ей сейчас надо на один операнд. А компилятор раскладывает независимые операции так, чтобы эффективнее загрузить все линии памяти. Раз уж VLIW вспомнили.