Войти
ФлеймФорумЖелезо

А если ли у нас ностальгирующие по MOS 6502? (6 стр)

Страницы: 15 6 7 811 Следующая »
#75
21:49, 1 дек. 2017

monobogdan
> Вроде как даже там на C писать проблематично, т.к медленный там
Писать на Си везде проблематично, если ты не представляешь выхлоп
компилятора и почему он именно такой и как его сделать другим +
наскипидаренный компилятор немного компенсирует незнание тонкостей
платформы. Если этого всего нету, то будет медленно. Особенно если
писать в неподходящем для данной платформы стиле.


#76
22:21, 1 дек. 2017

exchg
у разных тулчейнов разный выхлоп будет.
Я думаю как раз под 6502 стоит использовать fastcall(вопрос только найдется ли столько регистров?), т.к озу там мало(если там стек в озу).

#77
22:53, 1 дек. 2017

Поразительно, что среда разработки Aztec С для Apple ][ позволяла компилировать модули как в коде 6502, так и в псевдокоде, и произвольно объединять их при линкинге. Рантайм занимал 3000 байт. В случае 6502 псевдокод приобретал особое значение, т.к. прямая компиляция в 8-битный код программ, оперирующих мультибайтными переменными, порождала монстров в смысле размера кода. Как все это удалось сделать в 64кб памяти - просто невероятно. Кстати, Aztec С поддерживал даже простые аналоги make файлов.

#78
23:50, 1 дек. 2017

monobogdan
> у разных тулчейнов разный выхлоп будет.
да, вот и примени знания/понимание чтобы выбрать оптимальный
компилятор/стиль кода.

monobogdan
> Я думаю как раз под 6502 стоит использовать fastcall(вопрос только найдется ли
> столько регистров?), т.к озу там мало(если там стек в озу).
глобалы/статики + зеропэйдж. фасткол все равно пропихивает через регистр только
один параметр.

#79
3:04, 2 дек. 2017

Вот здесь: http://www.gamedev.ru/flame/forum/?id=216249 можно почитать про исследование асмовыхлопа компилятора Hisoft Pascal на ZX Spectrum (процессор Z80), а оттуда же по первой ссылке - асмовыхлопа компилятора Hisoft C.
Общая мораль примерно такая: ассемблер рулит, компиляторы дают просадку производительности примерно на порядок, интерпретаторы - два-три порядка.
Проблема компилятора в общем то как раз в том, что он не умеет производить регистровых оптимизаций и все операции производит с памятью, медленно и печатльно загружая-выгружая в неё содержимое промежуточных вычислений.
Ну и гигантские прологи/эпилоги не всегда уместные для коротких функций, не говоря уже про leafnode-функции. Плюс еще реентерабельность тоже штука не бесплатная и от неё зачастую в то время можно было отказаться тоже.
Поэтому да, на денди в то время, в сфере высокопроизводительных игровых решений Си не было места.

#80
8:29, 2 дек. 2017

exchg
> да, вот и примени знания/понимание чтобы выбрать оптимальный
> компилятор/стиль кода.
вроде как cc65 самый старый из современных компиляторов, я думаю он генерирует нормальный код.
Мой стиль? Ну он в основном на ООП завязан, даже под C я могу использовать классы(структуры + указатель на функцию), хотя под cc65 даже лишний раз функцию не нужно вызывать(лучше оформить в виде макроса, на x86 вызов ничего не отъедает, а на cc65 это отъест либо стек либо регистры а потом будет стек чистить что отъест некоторое время).

exchg
> фасткол все равно пропихивает через регистр только
> один параметр.
в юниксах все syscalls используют fastcall, и если 6 аргументов не достаточно то передает один из аргументов как структуру.
Не знаю насколько это жирно в условиях cc65.

Кстати, в 6502 можно было писать напрямую в IP? Или приходилось записывать в специальный регистр адрес возврата(как в x86). Речь о call.

#81
9:40, 2 дек. 2017

Из хисофтовых компиляторов ещё кое как Паскаль работал (даже тетрис написали). Си вообще какую-то дичь генерировал и библиотек нормальных не было.
Говнокодить с классами и темплейтами на 8битный CPU? Ну это совсем не айс. Не сильно лучше интерпретатора Бейсика будет. Так что только асм, только хардкор. 

#82
10:16, 2 дек. 2017

Dexus
> ещё кое как Паскаль работал
ну так в паскале есть намертво прибитые конструкции типа writeln которые если удалить - будет не pascal.
И в том то и дело что эти writeln тащат за собой драгоценную память(про AssignFile на коммодоре не знаю, там вроде вообще не было File IO).
Так что по размеру оно должно выйти потяжелее.

#83
10:18, 2 дек. 2017

Dexus
> Так что только асм, только хардкор. 

Ну не знаю, для Z80  SDCС даёт неплохой, в принципе, код. Особенно если асмовставками разбавить.

#84
10:34, 2 дек. 2017

0iStalker
> Ну не знаю, для Z80 SDCС даёт неплохой, в принципе, код
Про современные кросскомпилеры я ничего не знаю, я говорил про Hisoft C под z80.

monobogdan
> Так что по размеру оно должно выйти потяжелее.
Потяжелее чем что? С асмом разумеется нечего и сравнивать...
На Hisoft C вообще не получилось сделать ничего вменяемого. Какое-то глючное Г получалось.

#85
10:36, 2 дек. 2017

Я посмотрел что делает CC65, гкхе, кхке... Мда уж...
С другой стороны да, рассеялись последние сомнения что примерно делали компиляторы C на этих платформах с zero-page. Да, как я и подозревал конкретно на 6502 творится адище с имитацией нехватающих регистров как ячеек в zero-page.
Даже уже немного стало формироваться понимание как там по правильному надо было программировать на ассемблере - таки дасс, полноценный стек и реентерабельность - в топку.

monobogdan
> cc65 самый старый из современных компиляторов, я думаю он генерирует нормальный код.

Нет, там адовое адище. Вот например как выглядит откомпилированная в CC65 функция:

char func( char a, char b )
{
  return a + b;
};
получается такой вот асмовыхлоп:
.proc  _func: near
  jsr     pusha
  ldy     #$00
  lda     (sp),y
  clc
  iny
  adc     (sp),y
  ldx     #$00
  jmp     incsp2
.endproc
Поменяем типы данных на int-ы:
.proc  _func: near
  jsr     pushax
  jsr     ldax0sp
  clc
  ldy     #$02
  adc     (sp),y
  pha
  txa
  iny
  adc     (sp),y
  tax
  pla
  jmp     incsp4
.endproc
В общем видно, что всё печально. На порядок медленее, чем полноценный асм.

#86
10:39, 2 дек. 2017

Dexus
Чем C.
Hisoft Pascal, если это был настоящий компилятор Pascal должен линковать модуль System с бинарником в котором есть реализация точки входа, возможно бэкэнды к writeln, readln ну и остальной рантайм.
В то время как C может вообще выдавать сырой бинарник на выводе вообще без стандартной библиотеки.

#87
10:39, 2 дек. 2017

Dexus
> На Hisoft C вообще не получилось сделать ничего вменяемого. Какое-то глючное Г
> получалось.

У меня он в принципе работал норм, но мне не хватило опыта в своё время чтобы выйти на функции иные чем зашитые в рантайм printf/scanf собственно из примеров.
Это, конечно, сильно ограничило применение, но глюков я не видел. Да и как бы это было бы странно - фирма то одна и та же.
С паскалем из-за наличия сразу многих штук во вшитой библиотеке действительно было круче.
Но там именно что проблема была в разнице между модулями си и паскаля, си сразу не предлагал почти ничего, а то что во внешних либах было - оно на кассеты то ли не пошло, то ли что, у меня его просто не было.

#88
10:41, 2 дек. 2017

=A=L=X=
там надо еще состояние для стека выбирать отдельной командой?
Было бы оно как в 8086 одной командой - push или pop то было бы проще, а так тратится время на переключение состояний.
А так да, не очень красиво.
Было бы интересно посмотреть тот же код с Hisoft C.

#89
10:47, 2 дек. 2017

Вообще какую модель взял создатель C65: т.к. регистров там было 3 - a,x,y и все 8-битные, а стек был калечный, то код предполагает следующее:
Регистра "a" является 8-битным аккумулятором, но если для вычислений нужно 16 бит, то он дополняется виртуально регистром x как регистровой парой x:a.
Аппаратный стек (s) используется для только для адресов возврата и временных перебросок - как это и было в платформе, ибо стек там не может быть больше 256 байт в принципе.
Стек же для передачи параметров и хранения локальных переменных называется C-stack и адрес его вершины хранится в переменной sp (16 бит) в zero-page.
Поэтому существует огромная куча утилитарных процедур, типа запушить на C-stack пару a:x или сложить 16-битно верхние два в стеке числа.
При этом если в эти процедуры заглядывать, то как я в первопосте и писал становится физически плохо, например упомянутая процедура помещения регистровой пары a:x в стек выглядит вот так:

.proc   pushax

        pha                     ; (3)
        lda     sp              ; (6)
        sec                     ; (8)
        sbc     #2              ; (10)
        sta     sp              ; (13)
        bcs     @L1             ; (17)
        dec     sp+1            ; (+5)
@L1:    ldy     #1              ; (19)
        txa                     ; (21)
        sta     (sp),y          ; (27)
        pla                     ; (31)
        dey                     ; (33)
        sta     (sp),y          ; (38)
        rts                     ; (44)     

.endproc
тут вот еще прекрасно видно в какой роли используется оставшийся регистр y - времянка для индексаций.

Страницы: 15 6 7 811 Следующая »
ФлеймФорумЖелезо