Комментарии 43
Музыку в ролик вставлять — читерство.
Ай-ай-ай.
Ай-ай-ай.
Чувствую лет через 10 можно будет в резюме писать «прокачал программиста 80 лвл в 0x10c»
Почему до сих пор поделки для DCPU-16 делаются на ассемблере?
Ни у кого руки не дошли до компилятора С, например?
Ни у кого руки не дошли до компилятора С, например?
Тут наверно лучше подойдёт Forth, нежели чем C.
не объясните человеку несведущему в forth чем он так хорош?
Я тоже мало знаком с Forth, но он же вроде как стэковый, нет? Его можно действительно эффективно компилировать в код, работающий в первую очередь с регистрами?
Вот тут, к сожалению, не могу ничего сказать конкретного. Но попытки написать форт-машину под DCPU-16 тем не менее уже имеются, что наверно говорит о том что с производительностью у неё в теории всё нормально.
; использование аппаратного стэка для данных - 6 циклов (почему-то операции со стэком стоят 0 циклов по спеке, хотя логично должно быть 2 минимум для PUSH и POP и 1 для PEEK)
SET A, POP ;1+1+0
DIV PEEK, A ;3+0+1
; использование "виртуального" стэка, Z - указатель, 8 циклов
DIV [1+Z], [Z] ; 3+1+1
ADD Z,1 ; 1+1+1
; использование переменных в памяти - 5 циклов
DIV [0x1000], [0x1001] ;3+1+1
Проигрыш минимален и вполне допустим, имхо. А в каких-то ситуациях будет выигрыш, например умножение на 2: ADD PEEK, PEEK — 1 цикл, ADD [0x1000], [0x1000] — 3 цикла
ADD стоит столько же, сколько MUL и SHL — 2 цикла. 1 цикл — только на битовые операции и на SET. Но со стеком будет заметный проигрыш при обращении к «глубоким» ячейкам: SET [1+X],[2+X] занимает 3 такта, поскольку смещения записаны в отдельных словах программы.
SET A, POP ;1
DIV PEEK, A; 3 ;;; 4 такта, 2 слова
DIV [1+Z], [Z]; 4
ADD Z,1; 2 ;;; 6 тактов, 3 слова
DIV [0x1000], [0x1001]; 5 тактов, 3 слова
SET A, POP ;1
DIV PEEK, A; 3 ;;; 4 такта, 2 слова
DIV [1+Z], [Z]; 4
ADD Z,1; 2 ;;; 6 тактов, 3 слова
DIV [0x1000], [0x1001]; 5 тактов, 3 слова
Вы привели ссылки по истории языка, а хотелось бы видеть ссылки на учебники, туториалы и т.п. Впрочем, лично я весьма скептически отношусь к Forth. Многие ругают Perl, называя его write-only языком — они ещё код на Forth не читали. Аргументы фортеров про простоту написания компилятора смехотворны: говоря метафорично, программисту обычно нужен рабочий парашют, а не возможность шить парашют в процессе падения. Делать компиляторы — удел спецов, нормальным людям нужно задачи решать. А выразительные средства Forth (если такие есть) этому не способствуют.
Я бы очень хотел увидеть пример чистого и понятного кода на Forth, но никто из встречавшихся в сети фортеров так мне его и не дал. Честно говоря, код на ассемблере мне кажется более понятным и приятным глазу.
Я бы очень хотел увидеть пример чистого и понятного кода на Forth, но никто из встречавшихся в сети фортеров так мне его и не дал. Честно говоря, код на ассемблере мне кажется более понятным и приятным глазу.
Вопрос был почему по моему мнению форт лучше C подходит для создания «высокоуровневого» языка на DCPU-16, посему и были даны ссылки на описания языка, а не учебники. Если же вам интересно введение в язык, то можете например начать отсюда. Там же приведены примеры читаемого кода, например мы можем оперировать размерностями словно у нас естественный язык:
Выдаст результат в миллиметрах сложения 10 футов и 3 метров, кроме того мы можем преобразовывать величины обратно:
Или например код управления роботом может иметь вид:
Насчёт же вашей попытки навязать холивор, могу сказать одно, что темой было именно написание парашюта под DCPU-16, поэтому лёгкость шитья здесь очень даже играет роль. В общем, гуглите сами и решайте сами интересен вам форт или нет, моего уровня компетенции не хватает что бы рассказывать скептикам о его преимуществах и недостатках, а так же спорить с ними о фломастерах.
254 10 UNITS INCHES
254 12 * 10 UNITS FEET
254 36 * 10 UNITS YARDS
10 1 UNITS CENTIMETERS
1000 1 UNITS METERS
10 FEET 3 METERS +
Выдаст результат в миллиметрах сложения 10 футов и 3 метров, кроме того мы можем преобразовывать величины обратно:
3048 AS FEETИли например код управления роботом может иметь вид:
2 TIMES LEFT EYE WINKНасчёт же вашей попытки навязать холивор, могу сказать одно, что темой было именно написание парашюта под DCPU-16, поэтому лёгкость шитья здесь очень даже играет роль. В общем, гуглите сами и решайте сами интересен вам форт или нет, моего уровня компетенции не хватает что бы рассказывать скептикам о его преимуществах и недостатках, а так же спорить с ними о фломастерах.
а ведь интересная идея, скомпилировать компилятор на псевдоязыке чтобы компилировать псевдопрограммы.
Yo dawg
We heard you like compilers so we put a compiler in your compiler so you can compile while you compiling!
We heard you like compilers so we put a compiler in your compiler so you can compile while you compiling!
А может ли кто-нибудь с абсолютной точностью сказать, что всё происходящее — реально?
Что, например, этот комментарий написан не только в моём сознании?
Что, например, этот комментарий написан не только в моём сознании?
Тут скорее надо кросскомпиляцию — оперативки маловато, внизу в комментах про llvm пишут, для gcc я думаю тоже кто-нибудь бэкенд сделает ;)
Есть lisp-dcpu с ограничениями.
Работы ведутся, как говорится.
В любом случае, ограничения железа такие, что у тех, кто будет писать программы на ассемблере может быть заметное преимущество перед пишущими на чем-то более высокоуровневом.
Знаю, что вот тут другим нашим соотечественником ведется разработка LLVM для DCPU.
В любом случае, ограничения железа такие, что у тех, кто будет писать программы на ассемблере может быть заметное преимущество перед пишущими на чем-то более высокоуровневом.
Знаю, что вот тут другим нашим соотечественником ведется разработка LLVM для DCPU.
По-моему даже неоптимизирующая компиляция Си или Си-подобного языка (все переменные «статические», никаких куч и прочей динамики) не сильно хуже ассемблера будет для данной архитектуры, где нет разницы по времени доступа к регистру, памяти им адресуемой, литералу, памяти, адресуемой литералом. Всё один цикл.
Да, но памяти очень мало. И скорость почти пропорциональна длине исполняемого кода. А любое обращение к переменной в глубине стека или в общей памяти — лишний такт.
По Z80 я помню, что какой-то C-компилятор (единственный, который был доступен — не помню, чей) давал код в 3 раза длиннее, чем результат ручной компиляции. Хотя, конечно, времена изменились, и компилятор может работать на заметно более мощной машине :)
По Z80 я помню, что какой-то C-компилятор (единственный, который был доступен — не помню, чей) давал код в 3 раза длиннее, чем результат ручной компиляции. Хотя, конечно, времена изменились, и компилятор может работать на заметно более мощной машине :)
Я специально написал «неоптимизирующий», имея в виду кросскомпиляцию на каком-нибудь i5 :)
Насчет «скорость пропорциональна длине, я, конечно, неправ. И постоянно стоит вопрос, что сейчас важнее — слова или такты. Какой-нибудь memset можно написать так, что он займет 7 слов и 7 тактов на элемент массива, а можно — в 21 слово и 1.4 такта на элемент. И иногда память важнее (например, в boot-секторе, если будет такое понятие).
По моему, по приведенной в статье ссылке на девелопертулзы куча компиляторов Це, Це-решеток и даже куВасик есть.
Знаете, я вам завидую. Судя по всему у вас просто дохрена времени.
Я, в общем-то, даже в статье упомянул, что определенно планирую :)
Пять, пожалуй, основных вещей, которые собираюсь реализовать:
Ну и, конечно, когда Нотч обновит спецификации (а он вроде обещался прислушаться ко всем отзывам сообщества) — адаптироваться к ним.
- Более «правильный» вывод на экран (цвета, шрифты)
- Макросы
- Сохранение/загрузку исходников и скомпилированного кода (хотел быстро это сделать, но понял, что придется прикручивать флэш, чтобы все работало только на клиенте, и немного притормозил)
- Какую-никакую подсветку синтаксиса (наверняка легко прикрутить готовое решение, но хочется самому с этим поразбираться)
- В эмуляторе — более комфортную работу с текущим содержимым памяти (сейчас там очень печальная прокрутка, а еще хочется сделать возможность посмотреть содержимое ячеек в разных системах счисления и менять их)
Ну и, конечно, когда Нотч обновит спецификации (а он вроде обещался прислушаться ко всем отзывам сообщества) — адаптироваться к ним.
Сохранение/загрузку исходников и скомпилированного кода (хотел быстро это сделать, но понял, что придется прикручивать флэш, чтобы все работало только на клиенте, и немного притормозил)
Пока вполне достаточно и localStorage обойтись. Но такими темпами на за горами тот день, когда на одном из подобных сайтов прикрутят git-репозитории для приложений и github hooks: )
Шлю значение event.keyCode, с небольшими заменами, которые подглядел в программах (написанных, по всей видимости, для других ассемблеров): Enter — 0x0a, стрелка влево — 0x01, вправо — 0x02, вверх — 0x03, вниз — 0x04.
Нормальной спецификации по вводу с клавиатуры пока нет, а Нотч писал, что будет его менять (можно будет в том числе ловить события keydown/keyup) — поэтому пока так.
Нормальной спецификации по вводу с клавиатуры пока нет, а Нотч писал, что будет его менять (можно будет в том числе ловить события keydown/keyup) — поэтому пока так.
Теперь макросы должны работать. Синтаксис такой же, как в примерах Нотча:
#macro push(a) {
set PUSH,a
}
#macro push(a,b) {
set PUSH,b
set PUSH,a
}
push(x, 1)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тетрис для DCPU-16