[06:38:20] <vlad3> Вообще на 8кб странно ожидать сборщика мусора.
[06:39:32] <vlad3> По поводу итераторов - посмотри в бусте. А лучше забей ;) Оно того не стоитю
[06:40:34] <vlad3> А полнолуние в разгаре.
[10:39:26] <valexеy> vlad2: штука в том, что 8 Кб это только у одного из дивайсов для котрого используется Astrobe
[10:41:01] <valexеy> Есть например дивайс где 40 Кб ОЗУ
[10:42:55] <valexеy> А есть дивайсы которые вообще с наращиваемой памятью (то есть туда можно воткнуть хоть мегабайт).
[10:47:51] <valexеy> Но естественно дальше одной модели у info21 заглянуть сил не хватит (а всего то и нужно что зайти на сайт Astrobe и посмотреть на модели плат)
[15:43:25] <valexey > "Большие системы разрабатывают с помощью HDL, а не схем. Схемы сильно устаревший способ представления схем, пардон за каламбур."
[16:33:09] <vlad3> Гы. Можно потроллить драконоидов ;)
[18:04:13] <egp> да дракон этот - просто ухудшенный вариант стейт-диаграмм UML
[18:04:34] <valexey > зато made in USSR
[18:04:47] <egp> добра-то
[18:08:01] <egp> я вот щас думаю что аналитическая философия - точнее философия анализа бытия - это язык для ии
[18:08:23] <egp> надо попробовать замутить ИИшный чат
[18:08:25] <valexey > а зачем нам ИИ? :-)
[18:08:30] <egp> я ИИшник
[18:09:05] <egp> просто мысля возникла, хотел сказануть
[18:10:00] <egp> а касательно оберона - я думаю вот что
[18:10:20] <egp> что правильнее некоторый абстрактный графовый формализм иметь
[18:10:34] <egp> а то как он сериализован в поток бит - уже не оч существенно
[18:11:03] <egp> то есть не язык
[18:11:06] <egp> иметь
[18:11:11] <egp> а иметь вот что
[18:11:29] <egp> некий мысленный формат графов
[18:11:47] <egp> для control flow.
[18:12:09] <egp> из этого можно строить высокоуровневые процы
[18:12:21] <egp> у меня вертится мысля на плисках такое замутить
[18:12:39] <egp> получится нечто типа оберон-процессора, пользуясь не очень подходящей терминологией
[18:13:06] <egp> ну мутить на плисках я вряд ли буду, но интересно попробовать бы
[18:13:42] <egp> то есть имеется в виду типа juice-процессора
[18:13:59] <egp> который берёт juice формат и напрямую его интерпретирует.
[18:14:48] <egp> получился бы очень прогрессивный чип
[18:15:27] <egp> точнее это не оберон-процессор, а juice-процессор.
[18:15:34] <egp> это лучше термин
[18:16:39] <egp> самого правильного термина нет, как нет термина для такого мысленного формата графов контрол флоу.
[18:20:40] <valexey > и чем же он правилен?
[18:22:09] <egp> тем что он квинтессенция оберона и си
[18:22:34] <valexey > эмм.. а чем эта квинтесенция отличается от квинтесенции джавы или там смалтолка?
[18:22:49] <valexey > алсо си-процессора уже были. равно как и жаба-процессора
[18:22:54] <valexey > и даже лисп-процессоры были
[18:22:58] <egp> у джавы есть генериксы... они в принципе вписываются
[18:23:19] <valexey > но какой с этого профит?
[18:23:24] <egp> а смолток - у него такой сыр-бор концепций вроде кложур что я поостерегусь о нём говорить
[18:24:13] <egp> профит - быстрая компиляция и возможность максимально оптимизировать проц без потери общности проца
[18:24:28] <valexey > у джавы нет генериков (если мы про джаву как среду а не язык).
[18:24:39] <egp> ну это реализация явы
[18:24:49] <egp> а в идеале генериксы надо протаскивать в проц
[18:25:03] <valexey > нет, это её суть. дженерики это всего лишь типизация. в рантайме они никак не роляют
[18:25:10] <egp> это не суть
[18:25:13] <valexey > а процессор занимается только рантаймом
[18:25:18] <egp> это реализация
[18:25:27] <egp> мне пофиг на их тупую спеку
[18:25:29] <egp> яверов
[18:25:48] <valexey > ок. тогда объясни на примерах как может быть реализована статическая типизация (те же дженерики) на уровне процессора
[18:25:58] <valexey > статическая, то есть не рантайм.
[18:26:08] <valexey > когда запустили приложение - уже поздно.
[18:26:11] <egp> ну хотя бы в памяти IR типа хранится с генериками
[18:26:17] <egp> проц может это почти не юзать
[18:26:20] <egp> но оно там
[18:26:37] <valexey > ЗАЧЕМ там хранить дженерики?
[18:26:38] <egp> IR - internal repr.
[18:26:47] <valexey > просто чтобы было?
[18:26:58] <egp> затем что проц должен оптимизировать выполнение проги
[18:27:10] <egp> а генерики позволяют оптимизировать лучше чем без них
[18:28:24] <egp> то что сейчас в яве - сделано для обратной совместимости и удешевления написания всей байды
[18:28:53] <egp> просто пришлось бы переписывать JVM и HotSpot
[18:29:01] <egp> а на это у них рука не поднялась.
[18:33:04] <egp> просто такой подход позволяет реализацию хотспота сдвинуть в железо
[18:33:14] <egp> а это уже значительно чудесатее :)
[18:35:30] <egp> кстати наверняка ни си-процы, ни ява-процы, ни лисп-процы не доходят до идеала
[18:35:37] <egp> дальше всех продвинулся вирт
[18:35:47] <egp> ну может ада ещё, я с ней не знакомился
[18:36:22] <egp> у явы плохизна в том что не juice а байткод
[18:36:33] <egp> у си в том что есть тип void*
[18:37:28] <egp> на void* надо бы выдавать компилер варнинг "THIS CODE IS BAD!!! void* IS CONSIDERED EVIL!!!"
[18:37:45] <egp> harmful, пардон
[18:38:36] <egp> короче войд* он же SYSTEM.ADDRESS - это модель ячейки-массив ячеек - адреса
[18:38:42] <egp> то есть низкоуровневая
[18:39:04] <egp> а указатель на тип или переменная некоего типа - это высокоуровневая модель
[18:39:12] <egp> и смешивать их нельзя
[18:39:18] <egp> и тем более кастить!
[18:39:24] <egp> каст вообще зло
[18:39:37] <egp> проц должен знать тип области памяти.
[18:40:05] <egp> то есть проц должен иметь указатель на область памяти И на IR-модель этой области памяти
[18:40:34] <egp> и такая ИР-модель для каждой области должна быть ОДНА!
[18:41:10] <egp> поэтому SYSTEM.ADDRESS он же войд* - НЕ НУЖЕН
[18:42:12] <egp> надо попробовать чото написать без использования систем.адрес
[18:42:28] <egp> начиная с оберон-транслятора у которого НЕТ систем.адрес
[18:42:59] <egp> это уже интересно, в отличие от транслятора в тухлый вонючий js :)
[18:54:16] <egp> valexey : кстати где-нить чонить пишут по теме "void* (aka SYSTEM.ADDRESS) considered harmful"?
[18:54:28] <egp> интересно взглянуть
[18:59:06] <egp> во
[18:59:34] <egp> опосля транслятора надо написать editor of embodied syntax
[19:00:07] <egp> то есть чтобы редактировались прямиком juice-файлы с возможностью комментов
[19:00:58] <egp> а textual form - это зло, его трудно рефакторить
[19:01:16] <valexey > egp: везде пишут что типизация нужна :-) void* - это работа без типов вообще (без динамической типизации и без статической типизации)
[19:01:57] <egp> ну это ладно. а вот даунсайды отсутствия типизации где описаны?
[19:02:14] <egp> и пробовал ли ктото без войд* систему сделать?
[19:02:41] <valexey > без вбивания адресов ручками (ака магические константы) ты ничего не сделаешь.
[19:02:48] <vlad2> Угу.
[19:02:50] <egp> почему?
[19:03:01] <valexey > потому что железяки работают именно так :-)
[19:03:10] <egp> я ж грю про процессор который бы всё это понимал!
[19:03:14] <vlad2> Хотя если heloo word - это тоже система, то можно.
[19:03:17] <egp> не
[19:03:20] <egp> не хелло
[19:03:27] <valexey > вот тебе нужно прописать свою процедуру в вектор прерывания, как ты это без адресов сделаешь?
[19:03:28] <egp> без потери общности надо
[19:03:32] <valexey > и без магических констант
[19:03:33] <vlad2> Ну компилятр - тоже можно ;)
[19:03:51] <valexey > vlad: он говорит про СИСТЕМУ
[19:04:05] <egp> константы ладно, типа волшебного номера вектора. но можно же дать им разные имена, этим векторам
[19:04:10] <valexey > так вот, в случае интимной близости с железякой ты без этого и hello world не напишешь
[19:04:29] <valexey > egp: и кто же им их даст? покажи как ты им дашь эти имена :-)
[19:04:47] <egp> нене. я имею в виду когда железяка спецом заточена под отсутствие войд*
[19:05:03] <valexey > адреса по которым эти вектора находятся - это просто числа.  а тебе их надо скастовать в указатели на функцию например
[19:05:33] <egp> вот в проце у кажного вектора будет указатель на его ИР-модель
[19:05:38] <egp> то есть на тип вектора
[19:05:54] <valexey > я откровенно не представляю как это будет выглядеть
[19:05:56] <egp> в пзу можно прошить типы векторов
[19:06:04] <egp> я тоже
[19:06:08] <egp> не представляю
[19:06:27] <egp> это будет просто массив векторов прерываний
[19:06:35] <egp> а
[19:06:37] <egp> нифига
[19:06:51] <valexey > что такое "просто массив векторов прерываний" с точки зрения процессора?
[19:07:17] <egp> ну у проца есть указатель на начало массива, и на тип этого массива
[19:07:45] <valexey > проц вообще не оперирует понятиями "указатель" и "массив" :-)
[19:07:47] <egp> и на массив типов функций-прерываний
[19:07:59] <egp> проц. можно же прошить?
[19:08:18] <egp> у проца-то будет низкоуровневая модель
[19:08:23] <valexey > нельзя
[19:08:28] <valexey > там нечего прошивать.
[19:08:42] <valexey > можешь взять FPGA и попробовать соорудить свой проц.
[19:09:08] <egp> у проца будет войд*, потому как этого _требуют_ микросхемы памяти
[19:09:15] <egp> НО
[19:09:25] <egp> у входного языка проца этого не будет
[19:09:30] <valexey > у проца может не быть микросхем памяти
[19:09:37] <egp> ну пусть будуд
[19:09:42] <valexey > /me как раз с такими работает
[19:09:58] <valexey > да и вообще такие процы чаще встречаются чем те у которых память в отдельных чипах
[19:10:10] <egp> ну это всё ладно. ща подумаю
[19:10:49] <egp> так вот. у входного языка проца можно типизировать каждый указатель
[19:11:12] <egp> то есть если мы даём ему адрес, то вместе с ним всегда даём адрес типа того адреса
[19:11:47] <egp> какая-то рекурсивная проблемка
[19:12:46] <valexey > главное, вопрос - зачем все это? :-) то есть ты чего хочешь добиться? зачем тебе в рантайме на уровне процессора типы? то есть зачем тебе динамическая типизация в процессоре?
[19:13:05] <egp> а хочу чтоб проц оптимизировал
[19:13:20] <valexey > проц не оптимизирует.  он тупо исполняет
[19:13:20] <egp> то есть транслировал в более низкоуровневое исполнение
[19:13:41] <egp> если его тупая исполнялка оптимизирует - то есть если проц навороченный
[19:13:47] <valexey > оптимизацию в более низкий уровень лучше делать на уровне компилятора
[19:13:48] <egp> то оптимизирует
[19:13:54] <egp> лучше и там и там
[19:14:21] <valexey > нет. всегда лучше только на уровне компилятора. поэтому, кстати, высокоуровневые процессора и закопали. они тупо не эффективны
[19:14:39] <egp> ха
[19:14:49] <egp> дак проблемы войд* не решили потому и закопали
[19:15:00] <egp> в лиспе сплошные типы-вариант - закопать
[19:15:07] <egp> в си - войд* - закопать
[19:15:12] <valexey > я подозреваю что у лисп-процессоров не было ни void* ни проблемы :-)
[19:15:15] <egp> в яве - байткод - закопать.
[19:15:25] <egp> у них есть проблема вариант-типов
[19:15:28] <egp> у лиспа
[19:15:29] <valexey > чем тебе байткод не устраивает? ;-)
[19:15:40] <egp> тем что его особо трудно оптимизировать
[19:15:59] <egp> чтобы его оптимизировать, нужно сперва превратить его в высокоуровневый код
[19:16:06] <valexey > у вариант-типа в каждый момент времени ты знаешь какой тип там внутри сидит. это просто динамическая типизация. это не void* который типа не имеет вообще никогда
[19:16:07] <egp> тоесть среверс инжинирить
[19:16:27] <egp> войд* - это оч похоже на вариант - тип
[19:16:34] <valexey > вообще не похож
[19:16:42] <egp> просто тип хранится не "где-то тут", а "довольно далеко"
[19:16:45] <egp> та же хрень
[19:17:00] <valexey > в void* тип не хранится вообще
[19:17:03] <egp> возможно тип хранится в мозгу у прогера
[19:17:11] <egp> так что совсем далеко :)
[19:17:15] <valexey > а возможно что и там не хранится
[19:17:39] <egp> ну короче неважно. Главное что вариант-тип тоже не соптимизируешь пока тип не вычислен
[19:17:51] <egp> на этапе объявления тип варианта неизвестен
[19:18:09] <valexey > то что ты предлагаешь - как раз вариант и есть :-) та же самая динамическая типизация
[19:18:15] <egp> нееее
[19:18:26] <egp> в обероне тоже легко сляпать варианты
[19:18:28] <valexey > а чтобы она была статической, она не должна до исполнителя (процессор) доходить вообще
[19:18:32] <egp> да не
[19:18:41] <egp> я хочу высокоуровневый проц замутить
[19:19:03] <valexey > то есть x86? ;-)
[19:19:06] <egp> не
[19:19:11] <egp> языковой
[19:19:26] <egp> без гоу ту
[19:19:29] <valexey > который во время работы на лету транслирует из высокоуровневого x86-кода низкоуровневый RISC-код который затем и исполняет.
[19:19:45] <egp> да это всё пассы
[19:19:48] <egp> это не то
[19:20:05] <egp> я хочу проц структурного программирования
[19:20:48] <valexey > а толку? структурное программирование во-первых тормозное, во-вторых низкоуровневое
[19:20:53] <egp> для начала можно попробовать замутить под будущий проц транслятор
[19:21:08] <egp> для начала можно замутить эмулятор будущего проца на ч86
[19:21:10] <egp> х
[19:21:27] <valexey > да хоть на jvm :-) ладно, я домой пойду пожалуй.
[19:21:28] <egp> оно с чего тормозное-то?
[19:21:50] <egp> не. jvm нафиг. оно падучее
[19:22:05] <egp> ну ок чао какао
[19:22:13] <egp> короче вы меня не переубедили
[19:22:17] <egp> своими векторами :)
[19:22:26] <egp> эта проблема обходится влёт
[19:36:27] <egp> а называться эта вся системка будет BEAUTY