Тетрис для DCPU-16

[@danmiru]

Музыку в ролик вставлять — читерство.
Ай-ай-ай.

[@deNULL]

Ну кому бы было интересно смотреть ролик в неловкой тишине :)

А как DCPU начнет поддерживать вывод звука — можно будет попробовать и мелодию в игру добавить.

[@danmiru]

Я инстинктивно дернулся читать код, как выводится музыка.
После запуска игры на двух эмуляторах успокоился.
Нельзя так, люди ж читают, интересуются.

[@deNULL]

Ох. Добавил пояснение в пост, чтобы больше никого не обескураживать :)

[@fader44]

Чувствую лет через 10 можно будет в резюме писать «прокачал программиста 80 лвл в 0x10^c»

[@gaelpa]

Почему до сих пор поделки для DCPU-16 делаются на ассемблере?
Ни у кого руки не дошли до компилятора С, например?

[@newpavlov]

Тут наверно лучше подойдёт Forth, нежели чем C.

[@Fedcomp]

не объясните человеку несведущему в forth чем он так хорош?

[@newpavlov]

Простота написания форт-машины по сравнению с компилятором C, производительность, расширяемость. Например, вкратце можно почитать тут или вот эту статью на хабре.
Сам я тоже спецом не являюсь, всего лишь учу потихоньку, так что аргументированно отстаивать позиции форта не смогу.

[@deNULL]

Я тоже мало знаком с Forth, но он же вроде как стэковый, нет? Его можно действительно эффективно компилировать в код, работающий в первую очередь с регистрами?

[@newpavlov]

Вот тут, к сожалению, не могу ничего сказать конкретного. Но попытки написать форт-машину под DCPU-16 тем не менее уже имеются, что наверно говорит о том что с производительностью у неё в теории всё нормально.

[@VolCh]

; использование аппаратного стэка для данных - 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 цикла

[@Mrrl]

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 слова

[@VolCh]

Упс, невнимательно спеки читал. Но всё равно, по-моему, качественного преимущества нет у «классического» подхода.

[@burjui]

Вы привели ссылки по истории языка, а хотелось бы видеть ссылки на учебники, туториалы и т.п. Впрочем, лично я весьма скептически отношусь к Forth. Многие ругают Perl, называя его write-only языком — они ещё код на Forth не читали. Аргументы фортеров про простоту написания компилятора смехотворны: говоря метафорично, программисту обычно нужен рабочий парашют, а не возможность шить парашют в процессе падения. Делать компиляторы — удел спецов, нормальным людям нужно задачи решать. А выразительные средства Forth (если такие есть) этому не способствуют.

Я бы очень хотел увидеть пример чистого и понятного кода на Forth, но никто из встречавшихся в сети фортеров так мне его и не дал. Честно говоря, код на ассемблере мне кажется более понятным и приятным глазу.

[@newpavlov]

Вопрос был почему по моему мнению форт лучше C подходит для создания «высокоуровневого» языка на 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, поэтому лёгкость шитья здесь очень даже играет роль. В общем, гуглите сами и решайте сами интересен вам форт или нет, моего уровня компетенции не хватает что бы рассказывать скептикам о его преимуществах и недостатках, а так же спорить с ними о фломастерах.

[@Fedcomp]

а ведь интересная идея, скомпилировать компилятор на псевдоязыке чтобы компилировать псевдопрограммы.

[@deNULL]

Yo dawg

We heard you like compilers so we put a compiler in your compiler so you can compile while you compiling!

[@de1337ed]

А может ли кто-нибудь с абсолютной точностью сказать, что всё происходящее — реально?
Что, например, этот комментарий написан не только в моём сознании?

[@Mrrl]

Все происходящее — результат симуляции на суперкомпьютере, которого вообще не существует — ни в этой Вселенной, ни в другой, ни самого по себе. Так что все реально :)

[@Fedcomp]

физики вроде как считают что нет ничего настоящего.

[@LeiTZ]

Тут скорее надо кросскомпиляцию — оперативки маловато, внизу в комментах про llvm пишут, для gcc я думаю тоже кто-нибудь бэкенд сделает ;)

[@Zelgadis]

Есть lisp-dcpu с ограничениями.

[@deNULL]

Работы ведутся, как говорится.

В любом случае, ограничения железа такие, что у тех, кто будет писать программы на ассемблере может быть заметное преимущество перед пишущими на чем-то более высокоуровневом.

Знаю, что вот тут другим нашим соотечественником ведется разработка LLVM для DCPU.

[@VolCh]

По-моему даже неоптимизирующая компиляция Си или Си-подобного языка (все переменные «статические», никаких куч и прочей динамики) не сильно хуже ассемблера будет для данной архитектуры, где нет разницы по времени доступа к регистру, памяти им адресуемой, литералу, памяти, адресуемой литералом. Всё один цикл.

[@Mrrl]

Да, но памяти очень мало. И скорость почти пропорциональна длине исполняемого кода. А любое обращение к переменной в глубине стека или в общей памяти — лишний такт.
По Z80 я помню, что какой-то C-компилятор (единственный, который был доступен — не помню, чей) давал код в 3 раза длиннее, чем результат ручной компиляции. Хотя, конечно, времена изменились, и компилятор может работать на заметно более мощной машине :)

[@VolCh]

Я специально написал «неоптимизирующий», имея в виду кросскомпиляцию на каком-нибудь i5 :)

[@Mrrl]

Насчет «скорость пропорциональна длине, я, конечно, неправ. И постоянно стоит вопрос, что сейчас важнее — слова или такты. Какой-нибудь memset можно написать так, что он займет 7 слов и 7 тактов на элемент массива, а можно — в 21 слово и 1.4 такта на элемент. И иногда память важнее (например, в boot-секторе, если будет такое понятие).

[@Int_13h]

По моему, по приведенной в статье ссылке на девелопертулзы куча компиляторов Це, Це-решеток и даже куВасик есть.

[@DIHALT]

Знаете, я вам завидую. Судя по всему у вас просто дохрена времени.

[@deNULL]

Я, в общем-то, даже в статье упомянул, что определенно планирую :)

[@deNULL]

Пять, пожалуй, основных вещей, которые собираюсь реализовать:

• Более «правильный» вывод на экран (цвета, шрифты)
• Макросы
• Сохранение/загрузку исходников и скомпилированного кода (хотел быстро это сделать, но понял, что придется прикручивать флэш, чтобы все работало только на клиенте, и немного притормозил)
• Какую-никакую подсветку синтаксиса (наверняка легко прикрутить готовое решение, но хочется самому с этим поразбираться)
• В эмуляторе — более комфортную работу с текущим содержимым памяти (сейчас там очень печальная прокрутка, а еще хочется сделать возможность посмотреть содержимое ячеек в разных системах счисления и менять их)

Ну и, конечно, когда Нотч обновит спецификации (а он вроде обещался прислушаться ко всем отзывам сообщества) — адаптироваться к ним.

[@potomushto]

Сохранение/загрузку исходников и скомпилированного кода (хотел быстро это сделать, но понял, что придется прикручивать флэш, чтобы все работало только на клиенте, и немного притормозил)

Пока вполне достаточно и localStorage обойтись. Но такими темпами на за горами тот день, когда на одном из подобных сайтов прикрутят git-репозитории для приложений и github hooks: )

[@deNULL]

Шлю значение event.keyCode, с небольшими заменами, которые подглядел в программах (написанных, по всей видимости, для других ассемблеров): Enter — 0x0a, стрелка влево — 0x01, вправо — 0x02, вверх — 0x03, вниз — 0x04.

Нормальной спецификации по вводу с клавиатуры пока нет, а Нотч писал, что будет его менять (можно будет в том числе ловить события keydown/keyup) — поэтому пока так.

[@deNULL]

Теперь макросы должны работать. Синтаксис такой же, как в примерах Нотча:

#macro push(a) {
	set PUSH,a
} 

#macro push(a,b) {
	set PUSH,b
	set PUSH,a
}

push(x, 1)

[@deNULL]

Ну это было вполне ожидаемое событие :)

Над запрыгиванием внутрь макросов подумаю, вроде бы в моей нынешней реализации это должно быть не очень трудно сделать.

[@readmaxym]

можно идти еще глубже — например Dwarf Fortress и машина Тьюринга или калькулятор