О моём новом няшном языке программирования на основе Брейнфака

testicula · 04-10-11 00:04:15

MOP3E пишет:

testicula пишет:
А можно поинтересоваться: в каких?
Да хотя бы циклы.
Бейсик:
for x = 1 to 10 'вход в цикл
.
.
.
next 'переход к следующему элементу или выход из цикла
STL (извини, ассемблер уже подзабыл, но тут практически идентичная картинка):
L 10 //загрузка в аккумулятор числа 10
T #counter //инициализация загруженным в аккумулятор числом 10 счётчика цикла
lab1: //собственно, вход в цикл
.
.
.
L #counter //загрузка счётчика цикла в аккумулятор
DEC 1 //декремент акккумулятора на 1
T #counter //сохранение аккумулятора обратно в счётчик цикла
L 0 //загрузка в аккумулятор нуля (значение счётчика цикла сдвигается во второй аккумулятор)
<I //проверка, достигли ли мы конца цикла (0 в аккумуляторе < #counter во втором аккумуляторе)
JC lab1 //если не достигли конца цикла - вернуться на начало
Добавлено спустя 07 мин 13 с:
testicula пишет:
Так а всё таки, в чём сложность ассемблера? В количестве команд которые нужно изучить? А может в архитектуре?
В том, что для достижения поставленной цели нужно писать в десять-двадцать раз больше кода, чем в ЯП высокого уровня. В необходимости постоянно держать в голове физическую модель ЦП и памяти. В отсутствии внятной и точной типизации (я за это и классический С недолюбливаю), когда переменная характеризуется исключительно числом бит и может содержать абсолютно что угодно. И, самое главное - ассемблер сегодня абсолютно неактуален. Он нужен только для разработки весьма небольшого количества софта, который как правило работает не на РС. Такие дела...

Количество требуемых команд для выполнения каждой задачи в низкоуровнёвом языке типа ассемблера естественно будет больше. Также трудно ожидать от ассемблера хорошей типизации - это не тот язык где это требуется.

Вообще, я не просил сравнивать высокоуровнёвые языки с низкоуровнёвыми ибо с разницей между ними всё ясно. Мой вопрос заключался в определении "сложности" языка.

Сложность языка - по определению - не "трудность выражения задания на нём", а "количество конструкций языка (синтаксических), или по другому "кирпичиков", которые нужно изучить для эффективного использования этого языка".

Так вот, я утверждаю что ассемблер сравним по сложности с С, так как количество конструкций в них близко. "Сложность" же о которой ты говоришь - это скорее твоё субъективное мнение (построенное на страхе от впервые увиденной чёрт знает сколько лет назад "книжке по асму для ДОСа"). И на его (ассемблера) непохожести на знакомые тебе языки.

Babusha · 04-10-11 00:34:20

MOP3E, но в приципе никто не мешает написать супер-пупер ассемблер с блекджеком и шлюхами с няшным и понятным синтаксисом.

Дестер · 04-10-11 01:40:57

pavel2403 пишет:

Кстати, пруф?

https://en.wikipedia.org/wiki/Modulo_operation - держи.

testicula · 04-10-11 02:53:46

MOP3E пишет:

Babusha пишет:
MOP3E, но в приципе никто не мешает написать супер-пупер ассемблер с блекджеком и шлюхами с няшным и понятным синтаксисом.
Зачем? У ассемблера осталась очень узкая ниша - драйвера под винды и программирование всяких микропроцессорных систем, для которых нет нормальных ЯП.

Драйвер под винды на асме.... Извини но бугага smile

Babusha · 04-10-11 12:47:39

Блин,вы вообще не в ту степь залезли, я наоборот хотел сделать асм для ПРОСТОТЫ, чтобы все циклы, переходы и т.д. сделать элементарными командами, только все получилось наоборот, получилось труднее, чем в бреинфаке, при этом, муторнее и в результате, больше кода.

Тайный хранитель · 04-10-11 13:20:14

Раз уж создаёшь, то можно компилятор выложить? Исходники?

Редактировался Тайный хранитель (04-10-11 13:24:58)

Babusha · 04-10-11 17:18:28

Тайный хранитель пишет:

Раз уж создаёшь, то можно компилятор выложить? Исходники?

Без проблем, выложу на гитхаб.

testicula · 04-10-11 17:31:04

Babusha пишет:

Тайный хранитель пишет:
Раз уж создаёшь, то можно компилятор выложить? Исходники?
Без проблем, выложу на гитхаб.

И нам расскажи.

Добавлено спустя 02 мин 16 с:

Babusha пишет:

Тайный хранитель пишет:
Раз уж создаёшь, то можно компилятор выложить? Исходники?
Без проблем, выложу на гитхаб.

Даёшь следующий движок SLOR-а написанный на брэйнфаке Babush-и!

Babusha · 04-10-11 17:50:20

https://github.com/Babusha/Brainfuck

Критика кода приветствуется

Редактировался Babusha (04-10-11 17:55:06)

testicula · 04-10-11 18:55:28

Babusha пишет:

https://github.com/Babusha/Brainfuck
Критика кода приветствуется

Гениальный код! smile

Только, пожалуйста, в "if (command == ByteCodeCommand["["])":
Во первых - существует конструкция switch() в языке.
Во вторых - каждое обращение к ByteCodeCommand[] - это поиск в хэше по ключу-строке. Это есть медленно (особенно учитывая количество этих вызовов в цикле симулятора).

Лучше использовать в таких случаях сразу константу и оператор switch():

static const int CMD_LEFT_SQ_BRACE = 0x0A;
...
switch (cmd) {
 ...
 case CMD_LEFT_SQ_BRACE:
   .... // emulate the command.
   break;

А так, всё нормально smile
Браво!

savuor · 04-10-11 19:08:14

testicula пишет:

Во вторых - каждое обращение к ByteCodeCommand[] - это поиск в хэше по ключу-строке. Это есть медленно (особенно учитывая количество этих вызовов в цикле симулятора).

Я Си-шарп не знаю, но там, наверное, можно в качестве ключа использовать отдельные символы вместо целых строк(раз уж такие строки). Тогда и switch будет актуален.

Babusha · 04-10-11 21:16:43

testicula пишет:

Только, пожалуйста, в "if (command == ByteCodeCommand["["])":
Во первых - существует конструкция switch() в языке.

Ой, я прекрасно про нее знаю, а if я использовал, потому-что в самом начале подумал что могут понадобится более сложные конструкции сравнения, где switch`а будет мало.

testicula пишет:

Во вторых - каждое обращение к ByteCodeCommand[] - это поиск в хэше по ключу-строке. Это есть медленно (особенно учитывая количество этих вызовов в цикле симулятора).

Я лично не хочу жертвовать производительностью (причем в ~20 жалких итераций) и терять красивый и понятный код.

Добавлено спустя 02 мин:

savuor пишет:

Я Си-шарп не знаю, но там, наверное, можно в качестве ключа использовать отдельные символы вместо целых строк(раз уж такие строки). Тогда и switch будет актуален.

В руби есть прикольная фигня, так и называется - symbols и начинается с ":"

user[:Babusha] = "Кул Шарп хакир!"

Добавлено спустя 03 мин 22 с:

MOP3E пишет:

простых команд для циклов, переходов и т.п

WTF? А jmp? loop?

Редактировался Babusha (04-10-11 21:17:08)

testicula · 04-10-11 21:40:04

Babusha пишет:

Ой, я прекрасно про нее знаю, а if я использовал, потому-что в самом начале подумал что могут понадобится более сложные конструкции сравнения, где switch`а будет мало.

Не понадобятся. Я гарантирую это smile

Babusha пишет:

Я лично не хочу жертвовать производительностью (причем в ~20 жалких итераций) и терять красивый и понятный код.

Ты жертвуешь производительностью на количество_поддерживаемых_команд * каждый оборот твоего симулятора. Это как минимум увеличивает временную сложность твоего алгоритма с O(N) до O(N*M), где N-количество исполненных опкодов, а M-количество самих опкодов.

То есть, простым языком, с твоим подходом (if, помноженный на лукапы в Dictionary), твой эмулятор будет "тормозить" всё больше с увеличением количества поддерживаемых команд.

Тогда как вариант со свитчем, с очень высокой вероятностью, протранслируется JIT-ом в "JMP [EBX*4]", что не меняет скорость твоего эмулятора с увеличением количества поддерживаемых опкодов. (я не беру в расчёт проблемы с кэшем, ибо, особенно учитывая C# и его JIT -- уже намного более труднопредсказуемо).

Если не веришь, тебе может быть интересно взглянуть на MSIL disassembly твоего кода, и кода со свитчом. Почувствуйте разницу wink

В любом случае, успеха в обучении. Ты на правильном пути! smile

Редактировался testicula (04-10-11 21:42:05)

Babusha · 06-10-11 00:58:46

testicula пишет:

Не понадобятся. Я гарантирую это

Оценив ситуацию сейчас, я тоже так считаю.

testicula пишет:

Ты жертвуешь производительностью на количество_поддерживаемых_команд * каждый оборот твоего симулятора. Это как минимум увеличивает временную сложность твоего алгоритма с O(N) до O(N*M), где N-количество исполненных опкодов, а M-количество самих опкодов.

Уговорил smile , все переписал, хотя

case 0x1: // + increment

мне нравится меньше, ну ладно.

Кстати, а какое придумать название?

testicula · 06-10-11 01:44:02

MOP3E пишет:

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

Ну Бабуша же делает интерпретатор конкретноно диалекта брэйнфака, а не "алгоритм любой сложности".

Теоретическое обоснование "минимума требуемых конструкция (ты видимо имел в виду "операций") для реализации "любого алгоритма", в данном случае, как минимум - не к месту, как максимум - смешно smile

Добавлено спустя 03 мин 35 с:

Babusha пишет:

Уговорил , все переписал, хотя
case 0x1: // + increment
мне нравится меньше, ну ладно.

Дык мне тоже не нравится:
Просто вместо твоего изначального Dictionary (который тут мало подходит), можно использовать:

enum Opcodes
{
     OP_ADD,
     OP_SHIFT,
     ...
}

и затем ...

switch (cmd) {
    case OP_SHIFT:
          acc <<= vm.stack.pop();
          break;
}

Шустро, и даже понятнее чем с Dictionary.

Как тебе?

Добавлено спустя 44 мин:

Babusha пишет:

testicula пишет:
Ты жертвуешь производительностью на количество_поддерживаемых_команд * каждый оборот твоего симулятора. Это как минимум увеличивает временную сложность твоего алгоритма с O(N) до O(N*M), где N-количество исполненных опкодов, а M-количество самих опкодов.
Уговорил , все переписал, хотя

Кстати, https://stackoverflow.com/questions/4490 … 8060#48060. Тебе может быть интересно.

Babusha · 06-10-11 17:51:18

А какое придумать название?

Форум StopLinux

Объявление

#26 04-10-11 00:04:15

Re: О моём новом няшном языке программирования на основе Брейнфака

#27 04-10-11 00:34:20

Re: О моём новом няшном языке программирования на основе Брейнфака

#28 04-10-11 01:40:57

Re: О моём новом няшном языке программирования на основе Брейнфака

#29 04-10-11 02:53:46

Re: О моём новом няшном языке программирования на основе Брейнфака

#30 04-10-11 12:47:39

Re: О моём новом няшном языке программирования на основе Брейнфака

#31 04-10-11 13:20:14

Re: О моём новом няшном языке программирования на основе Брейнфака

#32 04-10-11 17:18:28

Re: О моём новом няшном языке программирования на основе Брейнфака

#33 04-10-11 17:31:04

Re: О моём новом няшном языке программирования на основе Брейнфака

#34 04-10-11 17:50:20

Re: О моём новом няшном языке программирования на основе Брейнфака

#35 04-10-11 18:55:28

Re: О моём новом няшном языке программирования на основе Брейнфака

#36 04-10-11 19:08:14

Re: О моём новом няшном языке программирования на основе Брейнфака

#37 04-10-11 21:16:43

Re: О моём новом няшном языке программирования на основе Брейнфака

#38 04-10-11 21:40:04

Re: О моём новом няшном языке программирования на основе Брейнфака

#39 06-10-11 00:58:46

Re: О моём новом няшном языке программирования на основе Брейнфака

#40 06-10-11 01:44:02

Re: О моём новом няшном языке программирования на основе Брейнфака

#41 06-10-11 17:51:18

Re: О моём новом няшном языке программирования на основе Брейнфака

Подвал форума