Комментарии 33
Это не ассемблер, а скорее ZX Spectrum Basic. У того тоже операторы были байт кодом. И выполнялся он в 60 раз медленнее ассемблера (правда, вмещался в 16кбайт ПЗУ).
Декомпилятор байт-кода 1С — существует?
Декомпилятор байт-кода 1С — существует?
У того тоже операторы были байт кодом.Нет. Просто операторы кодировались одним байтом, для экономии места (ну и ещё пара трюков была).
"Ассемблер" в данном случае условное название. Это байткод. Как MSIL для .NET
Декомпилятор байт-кода 1С — существует?
Да, существует, как и для большинства других стековых байт-кодов.
Сделай Форт для этого ассемблера и пишите на нем.
чёрт, по заголовку уже была морально готова увидеть
ДОБ eax, 5
ПЕРЕМ eax, ebx
МИНУС eax, 20
УМНОЖ ebx, 4
CРАВН ebx, 20
ПРЫГЕСЛИПРАВДА L1
ПРЫГ L2
...
1С-ники жалуются на свою систему, считая язык 1С недостаточно низкоуровневым
Я когда работал с 1с скорее жаловался на недостаточную высокоуровневость. Невозможно свои абстракции строить кроме примитивного деления на объекты метаданных, модули, и деления кода на функции с процедурами. Плюс к этому очень большая беда с инструментами (изи IDEA даже выходить не хочется в отличие от), беда с коммьюнити и практиками разработки, и чертова динамическая типизация.
От «честных» нативных языков в строю остался, пожалуй, только Си (с плюсами и без). Это если брать промышленный мейнстрим. Все популярные языки так или иначе имеют прослойку в виде «исполняющей среды» или «виртуальной машины», которая обеспечивает выполнение кода на той или иной архитектуре железа.
А в какую категорию отнесете dart, go, swift, kotlin native, rust и прочее? Ну ладно дарт с котлином и растом, но уж go со свифтом, куда уж мейнстримнее? Или наличие вообще любого рантайма считаете уже не честным?
А в Андроидах используется (или использовалась) регистровая машина Dalvik. Ходят слухи, что ее оттуда выпилили, но я не проверял.Не совсем выпилили. Заменили на ART который как умеет исполнять dalvik executable формат байткода (ну т.е. он его переводит в odex предварительно, но тот насколько знаю просто немного оптимизированный dex), т.е. тоже регистровой виртуальной машиной является, так и jit компилировать его, и даже aot компилировать когда собирает информацию о профилях использования и находится в простое на зарядке, тем самым получая уже нативный машинный код.
А за статью спасибо. Любопытно. Правда кажется если не ее, то что то очень похожее я уже читал где то. Возможно на том же инфостарте.
Или наличие вообще любого рантайма считаете уже не честным
Ну вопрос "честности" он, прямо скажем, субъективный. С одной стороны — да, наличие рантайма который что-либо делает за тебя (собирает мусор, например) это уж не совсем голый код. С другой стороны, если по теме статьи, то GO все-таки не стековый рантайм. Хотя, критикуемый Вами абзац — он про рантаймы вообще, а не только про стековые.
Считаю что сборка мусора, информация о типах и всякие прочие плюшки все не являются мерилом нативный язык или нет. Как по мне главный вопрос во что компилируется написанный пользователем код. Одно дело когда в байткод который исполняется или джитится виртуальной машиной, а другое дело когда в машинные инструкции рассчитанные на конкретную ОС и архитектуру процессора (пусть управлением памятью и некоторыми плюшками и занимается рантайм).
Еще раз, если взять конкретный абзац текста, то там имелось в виду, что голых языков осталось мало, разве что Си. А в остальных есть какой-то рантайм. Он необязательно плохой, медленный и т.п. Я имел в виду лишь то, что он есть.
Ну тогда можно сказать что и C не подходит))
А машинные инструкции потом не выполняются железом, а трнслируются куда скажет Crusoe ?
Обработка не собирается, версия платформы 8.3.11.3034
Даёшь компилятор из LLVM в opCode 1С? Ну, правда LLVM это регистровая машина, а 1С — стековая — но, вроде бы это не помеха, разве что с оптимизацией доступа к памяти будет лажа.
Ну а ещё — прикольно было бы свой компилятор для расширенной версии языка сделать! Чтобы не жаловались те, кто считает 1С не достаточно высоуровневым языком — ведь по сути, большая часть высокоуровневых абстракций современных языков — это лишь обёртки над примитивными структурами данных и процедурным стилем программирования! Ну разве что многопоточность требует поддержки со стороны ядра среды выполнения (стековой машины); ну и некоторые другие низкоуровневые штучки — упирающиеся отсутвие низкуровневого API (хотя в 1С это как раз можно расширить через нативные внешние компоненты, создаваемые на С++ — пусть и с некоторой потерей производительности — на кросс-вызовы). Ну а многопоточность — да — краеугольный камень в 1С (я не о фоновых заданиях — что больше сравнимы с фоново выполняемыми сервисами, причём только в серверном контексте, чем с потоками). Ну если не с многопоточностью, то с асинхронным программированием уж точно можно было бы поэкспериментировать — например как это сделано в Го с горутинами, или в Котлин с корутинами. Да на крайняк — сделать как в C# с задачами и async/await — но без многопоточности — то есть эмулировать асинхронность путём реализации гибкого управления стековым выполнением кода в одном потоке — конечно это идея сложная — и я тут просто так о ней написал — вдруг найдутся страждущие экспериментаторы!
А, вот, иные современные расширения для языка 1С сделать куда проще — хоть инициализаторы коллекций, хоть классы, с интерфейсами, свойствами и наследованием ввести, хоть, делегаты с анонимными функциями, функциями высшего порядка, хоть лямбда функции, и другие элементы функционального программирования. Хоть интегрировать контрактное программирование в платформу с динамической типизацией.
И сделать, наконец, поддержку вложенности модулей, структурные реквизиты, и наследование метаданных — хотя это уже напрямую к языку не относится — хотя вполне реализуем и на текущем движке платформы (правда тут и препроцессинга хватило бы).
Ну про макросы и расширенный препроцессинг — я промолчу уж — это задачи уже не для расширенного компилятора а, тоже, для препроцессора!
Ну а ещё — прикольно было бы свой компилятор для расширенной версии языка сделать! Чтобы не жаловались те, кто считает 1С не достаточно высоуровневым языком — ведь по сути, большая часть высокоуровневых абстракций современных языков — это лишь обёртки над примитивными структурами данных и процедурным стилем программирования! Ну разве что многопоточность требует поддержки со стороны ядра среды выполнения (стековой машины); ну и некоторые другие низкоуровневые штучки — упирающиеся отсутвие низкуровневого API (хотя в 1С это как раз можно расширить через нативные внешние компоненты, создаваемые на С++ — пусть и с некоторой потерей производительности — на кросс-вызовы). Ну а многопоточность — да — краеугольный камень в 1С (я не о фоновых заданиях — что больше сравнимы с фоново выполняемыми сервисами, причём только в серверном контексте, чем с потоками). Ну если не с многопоточностью, то с асинхронным программированием уж точно можно было бы поэкспериментировать — например как это сделано в Го с горутинами, или в Котлин с корутинами. Да на крайняк — сделать как в C# с задачами и async/await — но без многопоточности — то есть эмулировать асинхронность путём реализации гибкого управления стековым выполнением кода в одном потоке — конечно это идея сложная — и я тут просто так о ней написал — вдруг найдутся страждущие экспериментаторы!
А, вот, иные современные расширения для языка 1С сделать куда проще — хоть инициализаторы коллекций, хоть классы, с интерфейсами, свойствами и наследованием ввести, хоть, делегаты с анонимными функциями, функциями высшего порядка, хоть лямбда функции, и другие элементы функционального программирования. Хоть интегрировать контрактное программирование в платформу с динамической типизацией.
И сделать, наконец, поддержку вложенности модулей, структурные реквизиты, и наследование метаданных — хотя это уже напрямую к языку не относится — хотя вполне реализуем и на текущем движке платформы (правда тут и препроцессинга хватило бы).
Ну про макросы и расширенный препроцессинг — я промолчу уж — это задачи уже не для расширенного компилятора а, тоже, для препроцессора!
К 1с выйдет довольно плохо прикрутить язык с более широкими возможностями без поддержки вендора поскольку это все же не только язык, но и фреймворк просто с кучей жестко заданных условий, колбеков которые нужно использовать и разных ограничений. И сборка мусора у 1с через подсчет ссылок, что в случае усложнения языка без доработок со стороны 1с создаст кучу проблем обычным 1сникам с управлением памятью и в итоге это все останется применимо только для полутора гиков для хобби проектов.
НЛО прилетело и опубликовало эту надпись здесь
И сборка мусора у 1с через подсчет ссылок
Разве это плохо само по себе? Да, не позволяет обнаруживать «закольцованные» неиспользуемые ссылки, но это вопрос отладки кмк.
В текущей версии языка это не сильно мешает, но если таки реализовать замыкания, классы, и прочие фишки современных языков — то придется за этим следить вручную. Тут программисты на swift с этим лажают, и даже на java допускают утечки памяти хотя у нее то сборщик мусора трассирующий, а ведь даже понятия слабых ссылок в 1с нет, и очень сомневаюсь что это можно реализовать без поддержки платформой такой концепции.
Ну, во-первых, это просто прикольно, это позволит вам лучше понимать устройство вашей системы и понять, как работают современные управляемые языки программирования. Это позволит вам прокачать навык хардкорного программиста и просить более высокую зарплату.
Реально? Это в каких таких компаниях? То есть, я понимаю такое в гуглояндексах. А какую экономическую выгоду это даст тому же 1С-франчу, чтобы она повысила за это зарплату?
На ум приходит разве что только возможность, более надежно защитить свою конфигурацию от пиратства.
Выгоду это даст специалисту. Понимая систему он лучше работает, больше делает, решает проблемы не только свои, но и коллегам помогает, объясняет. Поэтому ему дают должность выше или он ее сам требует или идет с новым багажом знаний на другую работу… Ну прописные истины же, неужели это нужно пояснять?
Это понятно. Непонятно только, зачем такому специалисту вообще оставаться в 1С. Человеку, который может так глубоко разбираться в программировании, гораздо лучше переходить на более современные технологии и идти в гуглояндексы или новомодные стартапы. Там и перспективы выше, и условия лучше, и задачи интереснее.
Там и перспективы выше, и условия лучше, и задачи интереснее.
Не согласен только с последним. Задачи в гуглоандексах могут оказаться вполне тривиальными, ну или рутинными. Интересные задачи не появляются в каких-то особенных компаниях, интересные задачи — они повсюду. Реверс-инжинирить 1С вполне себе интересная задача, даже если за нее не дадут повышение и не повысят зарплату. Это просто интересная задача.
Класс! Так и до компилятора для альтернативных языков можно дойти
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
1С: Ассемблер — пишем чистый байт-код для стековой машины 1С: Предприятие