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 пишет:Так а всё таки, в чём сложность ассемблера? В количестве команд которые нужно изучить? А может в архитектуре?
В том, что для достижения поставленной цели нужно писать в десять-двадцать раз больше кода, чем в ЯП высокого уровня. В необходимости постоянно держать в голове физическую модель ЦП и памяти. В отсутствии внятной и точной типизации (я за это и классический С недолюбливаю), когда переменная характеризуется исключительно числом бит и может содержать абсолютно что угодно. И, самое главное - ассемблер сегодня абсолютно неактуален. Он нужен только для разработки весьма небольшого количества софта, который как правило работает не на РС. Такие дела...
Количество требуемых команд для выполнения каждой задачи в низкоуровнёвом языке типа ассемблера естественно будет больше. Также трудно ожидать от ассемблера хорошей типизации - это не тот язык где это требуется.
Вообще, я не просил сравнивать высокоуровнёвые языки с низкоуровнёвыми ибо с разницей между ними всё ясно. Мой вопрос заключался в определении "сложности" языка.
Сложность языка - по определению - не "трудность выражения задания на нём", а "количество конструкций языка (синтаксических), или по другому "кирпичиков", которые нужно изучить для эффективного использования этого языка".
Так вот, я утверждаю что ассемблер сравним по сложности с С, так как количество конструкций в них близко. "Сложность" же о которой ты говоришь - это скорее твоё субъективное мнение (построенное на страхе от впервые увиденной чёрт знает сколько лет назад "книжке по асму для ДОСа"). И на его (ассемблера) непохожести на знакомые тебе языки.
- Модератор... ты очень, очень глубоко заблуждаешься...
- Два предупреждения за скрытый мат!
Неактивен
MOP3E, но в приципе никто не мешает написать супер-пупер ассемблер с блекджеком и шлюхами с няшным и понятным синтаксисом.
Неактивен
Кстати, пруф?
Неактивен
Babusha пишет:MOP3E, но в приципе никто не мешает написать супер-пупер ассемблер с блекджеком и шлюхами с няшным и понятным синтаксисом.
Зачем? У ассемблера осталась очень узкая ниша - драйвера под винды и программирование всяких микропроцессорных систем, для которых нет нормальных ЯП.
Драйвер под винды на асме.... Извини но бугага
- Модератор... ты очень, очень глубоко заблуждаешься...
- Два предупреждения за скрытый мат!
Неактивен
Блин,вы вообще не в ту степь залезли, я наоборот хотел сделать асм для ПРОСТОТЫ, чтобы все циклы, переходы и т.д. сделать элементарными командами, только все получилось наоборот, получилось труднее, чем в бреинфаке, при этом, муторнее и в результате, больше кода.
Неактивен
Раз уж создаёшь, то можно компилятор выложить? Исходники?
Редактировался Тайный хранитель (04-10-11 13:24:58)
Кто на человека говорит или учит говорить антоним слова умный, тому от Христа Врача и Бога в ответ: ”сам такой”.
Неактивен
Раз уж создаёшь, то можно компилятор выложить? Исходники?
Без проблем, выложу на гитхаб.
Неактивен
Тайный хранитель пишет:Раз уж создаёшь, то можно компилятор выложить? Исходники?
Без проблем, выложу на гитхаб.
И нам расскажи.
Добавлено спустя 02 мин 16 с:
Тайный хранитель пишет:Раз уж создаёшь, то можно компилятор выложить? Исходники?
Без проблем, выложу на гитхаб.
Даёшь следующий движок SLOR-а написанный на брэйнфаке Babush-и!
- Модератор... ты очень, очень глубоко заблуждаешься...
- Два предупреждения за скрытый мат!
Неактивен
https://github.com/Babusha/Brainfuck
Критика кода приветствуется
Редактировался Babusha (04-10-11 17:55:06)
Неактивен
https://github.com/Babusha/Brainfuck
Критика кода приветствуется
Гениальный код!
Только, пожалуйста, в "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;
А так, всё нормально
Браво!
- Модератор... ты очень, очень глубоко заблуждаешься...
- Два предупреждения за скрытый мат!
Неактивен
Во вторых - каждое обращение к ByteCodeCommand[] - это поиск в хэше по ключу-строке. Это есть медленно (особенно учитывая количество этих вызовов в цикле симулятора).
Я Си-шарп не знаю, но там, наверное, можно в качестве ключа использовать отдельные символы вместо целых строк(раз уж такие строки). Тогда и switch будет актуален.
За каждым подвигом стоит чье-то разгильдяйство.
Кому я нужен, могут найти меня вконтакте, ник тот же.
Неактивен
Только, пожалуйста, в "if (command == ByteCodeCommand["["])":
Во первых - существует конструкция switch() в языке.
Ой, я прекрасно про нее знаю, а if я использовал, потому-что в самом начале подумал что могут понадобится более сложные конструкции сравнения, где switch`а будет мало.
Во вторых - каждое обращение к ByteCodeCommand[] - это поиск в хэше по ключу-строке. Это есть медленно (особенно учитывая количество этих вызовов в цикле симулятора).
Я лично не хочу жертвовать производительностью (причем в ~20 жалких итераций) и терять красивый и понятный код.
Добавлено спустя 02 мин:
Я Си-шарп не знаю, но там, наверное, можно в качестве ключа использовать отдельные символы вместо целых строк(раз уж такие строки). Тогда и switch будет актуален.
В руби есть прикольная фигня, так и называется - symbols и начинается с ":"
user[:Babusha] = "Кул Шарп хакир!"
Добавлено спустя 03 мин 22 с:
простых команд для циклов, переходов и т.п
WTF? А jmp? loop?
Редактировался Babusha (04-10-11 21:17:08)
Неактивен
Ой, я прекрасно про нее знаю, а if я использовал, потому-что в самом начале подумал что могут понадобится более сложные конструкции сравнения, где switch`а будет мало.
Не понадобятся. Я гарантирую это
Я лично не хочу жертвовать производительностью (причем в ~20 жалких итераций) и терять красивый и понятный код.
Ты жертвуешь производительностью на количество_поддерживаемых_команд * каждый оборот твоего симулятора. Это как минимум увеличивает временную сложность твоего алгоритма с O(N) до O(N*M), где N-количество исполненных опкодов, а M-количество самих опкодов.
То есть, простым языком, с твоим подходом (if, помноженный на лукапы в Dictionary), твой эмулятор будет "тормозить" всё больше с увеличением количества поддерживаемых команд.
Тогда как вариант со свитчем, с очень высокой вероятностью, протранслируется JIT-ом в "JMP [EBX*4]", что не меняет скорость твоего эмулятора с увеличением количества поддерживаемых опкодов. (я не беру в расчёт проблемы с кэшем, ибо, особенно учитывая C# и его JIT -- уже намного более труднопредсказуемо).
Если не веришь, тебе может быть интересно взглянуть на MSIL disassembly твоего кода, и кода со свитчом. Почувствуйте разницу
В любом случае, успеха в обучении. Ты на правильном пути!
Редактировался testicula (04-10-11 21:42:05)
- Модератор... ты очень, очень глубоко заблуждаешься...
- Два предупреждения за скрытый мат!
Неактивен
Не понадобятся. Я гарантирую это
Оценив ситуацию сейчас, я тоже так считаю.
Ты жертвуешь производительностью на количество_поддерживаемых_команд * каждый оборот твоего симулятора. Это как минимум увеличивает временную сложность твоего алгоритма с O(N) до O(N*M), где N-количество исполненных опкодов, а M-количество самих опкодов.
Уговорил , все переписал, хотя
case 0x1: // + increment
мне нравится меньше, ну ладно.
Кстати, а какое придумать название?
Неактивен
Насколько я помню курс информатики, необходимыми и достаточными конструкциями для разработки алгоритма любой сложности являются:
Ну Бабуша же делает интерпретатор конкретноно диалекта брэйнфака, а не "алгоритм любой сложности".
Теоретическое обоснование "минимума требуемых конструкция (ты видимо имел в виду "операций") для реализации "любого алгоритма", в данном случае, как минимум - не к месту, как максимум - смешно
Добавлено спустя 03 мин 35 с:
Уговорил , все переписал, хотя
case 0x1: // + increment
мне нравится меньше, ну ладно.
Дык мне тоже не нравится:
Просто вместо твоего изначального Dictionary (который тут мало подходит), можно использовать:
enum Opcodes
{
OP_ADD,
OP_SHIFT,
...
}
и затем ...
switch (cmd) {
case OP_SHIFT:
acc <<= vm.stack.pop();
break;
}
Шустро, и даже понятнее чем с Dictionary.
Как тебе?
Добавлено спустя 44 мин:
testicula пишет:
Ты жертвуешь производительностью на количество_поддерживаемых_команд * каждый оборот твоего симулятора. Это как минимум увеличивает временную сложность твоего алгоритма с O(N) до O(N*M), где N-количество исполненных опкодов, а M-количество самих опкодов.
Уговорил , все переписал, хотя
Кстати, http://stackoverflow.com/questions/4490 … 8060#48060. Тебе может быть интересно.
- Модератор... ты очень, очень глубоко заблуждаешься...
- Два предупреждения за скрытый мат!
Неактивен
А какое придумать название?
Неактивен