nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 21 May 2018 07:03



Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next
Программирование на CP/M компиляторах ЯВУ для рэтро ЭВМ 
Author Message
Writer

Joined: 19 Feb 2017 04:46
Posts: 23
Location: 600 км от Москвы
Reply with quote
.
Не нашёл раздела, где можно вести речь о программировании для рэтро ЭВМ, потому создал эту тему в разделе РК. Хотя тип ЭВМ тут не важен.

Вообще по идее должен быть раздел "Программирование для рэтро ЭВМ", т.к именно это самая интересная часть в хобби по рэтро компьютерам. Тогда там можно создать раздел "Программирование на Си", "Программирование на Паскале". А вот темы "Программирование на ассемблере" может быть стоит организовывать для каждого конкретного комппьютера, т.к при этом речь в основном о программировании по конкретному железу.

А ещё в разделах по каждому рэтро компьютеру не хватает раздела "Разное", где удобно задавать и обсуждать мелкие вопросы, ради которых нет смысла создавать целую тему.

Несколько дней назад я решил освоить программирование на Паскале МТ+ для РК86.

Почему именно для РК86? Потому что программа странслированная на ЯВУ работает примерно в 5-6 медленнее, чем программа написанная на ассемблере. А т.к вывод на экран в чисто текстовой машине происходит примерно в 25-50 раз быстрее, чем в графической, то это даёт основание предполагать, что для РК скоростей странслированной на ЯВУ программы хватит.

Почему именно на Паскале? А не на Си или Коболе? Потому что Паскаль мне почему-то приятнее, симпатичнее, чем Си, хотя при программировании разницы никакой нет, а по удобочитаемости исходников Си даже лучше. А почему МТ+ можно почитать здесь.

Кроме того, при 8-ми разрядке для игр чисто графический режим невыгоден из-за нехватки скорости, да и из-за логики работы игр, в которых надо перемещать не точки, а большие спрайты. Именно потому для игровых консолей выгоден принцип Дэнди, где спрайты рисуются не полноценной графикой а выводятся графическими тайлами, практически в текстовый адаптер. Визуально это равноценно полноценной графике, но загрузка процессора намного ниже.

Для РК86 уже разработаны две схемы, позволяющие загрузку фонтов. Но мне паять даже всего 7-8 микросхем на отдельной платке лениво, т.к практически тот же самый результат получается за 3 секунды работы путём припайки одного куска проволоки. Так на моём РК сделано с начала 90-тых (т.к в ПЗУ РФ2 умещаются два фонта, основной и альтернативный).

Из-за того что, несмотря на статью о фонтах в РК в ж.РАДИО, ни у кого не хватило ума опубликовать конкретную, готовую доработку, а точнее просто задать сдандарт как и какими битами переключать фонт ПЗУ, то для РК так и не появилось игр с красивой полноценной графикой и системных программ с окнами и нормальными графическими рамками.

Только я использовал альтернативный фонт, чтобы поиметь нормальную графику и окна в системных программах РК86. Посмотрите насколько нормальная графика (получаемая за счёт расхода в один кусок проволоки) выглядит лучше, чем убогая матрично-символьная графика с размером пикселей в 4*3 точки.

 что даёт на РК86 расход в один кусок проволоки
.
Image

Image

Image

Image

Image

Image

Image

Image
.


Но ведь кроме этого, альтернативный фонт, при прошивке в него тайлов для рисования красивых спрайтов позволяет сделать красивые игры для РК86. А Паскаль позволяет существенно облегчить программирование. Эти две идеи вместе позволяют с минимальной трудозатратой начать делать игры для РК86, пусть и не лучше, но имеющие по-крайней мере более красивый дизайн, чем имеющиеся игры РК86, изображаемые бегающими по экрану буквами.

Я об этом писал ещё пол-года назад, но реакции - ноль. Ясно, что это потому что для РК осталось всего 2.5 программиста любителя, к тому же уже погрязших в ассемблере. Потому ничего другого не остаётся как самому попробовать.

За несколько дней я прочитал документацию, изучил Паскаль и странслировал десяток программ. При этом убедился, что на Паскале МТ+ можно писать программы во много раз быстрее, чем на ассемблере, практически не имея никаких ограничений. Например, RAM-монитор я написал на Паскале за несколько часов, тогда как на ассемблере это занимает несколько дней.

Интерфейс с стандартными подпрограммами РК делается совсем просто за счёт INLINE вставок на ассемблере. Например, вот так:

 Интерфейс из МТ+ с подпрограммами ПЗУ РК86
Code:
procedure hex(BYT: byte);
begin
   inline( "LDA/BYT/
           "CALL/$F815 );
end;

procedure cout(SYM: char);
begin
   inline( "LDA/SYM /
           "MOV C,A /
           "CALL/$F809 );
end;

procedure cls;
begin
  INLINE( "MVI C/$1F/
          "CALL/$F809 );
end;

function conin: char;
var
RESULT: integer;
begin
   INLINE( "CALL/$F803/
           "MOV L,A/
           "MVI H/0/
           "SHLD/RESULT );
   conin := LO(RESULT);
end;

function XF81B: integer;
var
RESULT: integer;
begin
   INLINE( "CALL/$F81B/
           "MOV L,A/
           "MVI H/0/
           "SHLD/RESULT );
   XF81B := RESULT;
end;

procedure mssg(stradr: ukchar);
begin
   INLINE( "LHLD/STRADR/
           "CALL/$F818 );
end;

function chsum(begad: word; endad: word): integer;
var
RESULT: integer;
begin
   INLINE ( "LHLD/ENDAD/
            "XCHG/
            "LHLD/BEGAD/
            "CALL/$F82A/
            "MOV L,C/
            "MOV H,B/
            "SHLD/RESULT );
   chsum := RESULT;
end;

procedure JMP(ADR: word);
begin
   INLINE( "LHLD/ADR/
           "PCHL );
end;
 
procedure gotoxy(X,Y: integer);
begin
   INLINE( "MVI C/$1B/
           "CALL/$F809/
           "MVI C/$59/
           "CALL/$F809 );
   cout(chr(32+Y));
   cout(chr(32+X));
end;


Как видите всё очень просто. И очень удобно в программированиии.

Но не могу догадаться как в INLINE вставках задавать адреса меток (в командах переходов, а ассемблер без переходов почти бесполезен). Дело в том, что Турбо-Паскаль допускает символьные метки, а МТ+ это стандартный классический Паскаль, где метки, как и в бейсике цифровые, т.е 0001...9999.

И если в INLINE Турбо Паскаля можно объявить метку, затем где-то написать MTK1: и после этого идентификатор MTK1 можно вставлять в INLINE ассемблерную вставку, то с цифровыми метками так не получается. Цифровую метку можно объявить и где-то вставить, но как на неё ссылаться из ассемблера. Если вставлять 0001, то это воспринимается ассемблером как цифра. Без сомнения, это как-то решено, но пока не знаю как.


Last edited by barsik on 29 Apr 2018 14:47, edited 3 times in total.



28 Apr 2018 11:36
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
barsik wrote:
Кроме того, при 8-ми разрядке для игр чисто графический режим невыгоден из-за нехватки скорости, да и из-за логики работы игр, в которых надо перемещать не точки, а большие спрайты.

Вот тут можно и возразить немного... Одна из первых графических игр на "Специалисте", которую
я расковыривал, чтобы чему-то научиться - была ZOO из журнала МК.

Я просто что-то правил в кодах и смотрел - а что из этого получится?
Ну и обнулил я из интересу циклы каких-то счетчиков, а это оказались задержки после вывода
спрайтов на экран...
Так персонажи так носились по экрану :o (а там была анимированная заставка), что от них как
будто оставался след, как от пуль в фильме "Матрица"... :wink:

И ощутил я, что 8-битник на 2 МГц - это весьма не хило! 8)
Тут всё еще зависит от структуры графического экрана, а в "Специлисте" он построен удобнее,
нежели в ZX-Spectrum, поэтому вывод на него быстрее, хотя и растр больше.


Что касается ЯВУ - мне очень захотелось ЯВУ компилирующего типа, когда я начал делать на
"Специалисте" рассчеты - интегрирование систем уравнений методом Рунге-Кутты с выводом
результатов на графический экран...
Так оказалось, что больше всего тормозит не вывод графики, а сам интерпретатор ВАСИК.
Ну и поскольку никаких Паскалей и С++ в от момент и в помине не было, мы другом нашли
по объявлениям компилятор ВАСИК у одной фирмы в Воронеже, правда он был под CP/M, но
мне казалось - достаточно перенаправить вызовы функций CP/M в аналоги в системном мониторе,
и всё будет работать...

Этот "фокус" не я придумал - есть под Микрошей отладчик DDT - он запускался с адреса 100Н,
что тогда было странно, т.к. в основном программы грузились с 0000Н.
Я поковырял DDT и выяснил, что ниже 100Н, он формирует при старте некую структуру, где есть
переходы на системные подпрограммы ПЗУ.
Интересно, что этот отладчик DDT понимал коды Z80, хотя и был в софте для Микроши. Ну и я понял
тогда, что его так портировали из-под CP/M.

Однако, с компилятором ВАСИК, который мы купили, этот фокус не прошел, скорее всего потому,
что CP/M я тогда практически не знал, и информацию взять было негде. :osad:

Честно говоря на сегодняшний день мне более интересен компилятор С++ под "Специалист".
Здесь у нас на форуме он есть, смотрел я его, но уж больно он убог и более напоминает
какой-то учебный проект... :-?

_________________
iLavr


28 Apr 2018 16:07
Profile
Novelist
User avatar

Joined: 11 Jun 2012 08:30
Posts: 46
Reply with quote
begoon писал когда-то в своем блоге:
Quote:
Знаю, что С - это начало всех начал, и при правильном использовании можно писать очень близко по эффективности к ассемблеру. Но, все же есть еще системы, где компилятору С сложно развернуться. Например, захотел я подыскать компилятор С для Intel 8080, чтобы замутить небанальную программу для Радио-86РК. Из реально собираемого я нашел только пару наследников знаменитого Small-C – smallc-85 и smallc-scc3.

Увы, для простейшей программы типа:
Code:
main() {
  static char a;
  for (a = 1; a < 10; ++a) {
     ++a;
  }
}

Генерируется адъ типа:
Code:
;main() {
main:
;  static char a;
    dseg
?2: ds  1
    cseg
;  for (a = 1; a < 10; ++a) {
    lxi h,?2
    push    h
    lxi h,1
    pop d
    call    ?pchar
?3:
    lxi h,?2
    call    ?gchar
    push    h
    lxi h,10
    pop d
    call    ?lt
    mov a,h
    ora l
    jnz ?5
    jmp ?6
?4:
    lxi h,?2
    push    h
    call    ?gchar
    inx h
    pop d
    call    ?pchar
    jmp ?3
?5:
;     ++a;
    lxi h,?2
    push    h
    call    ?gchar
    inx h
    pop d
    call    ?pchar
;  }
    jmp ?4
?6:
;}
?1:
    ret

Понятно, что много вопросов к компилятору, но в целом, Intel 8080 не очень удобен для компилятора С: деления/умножения нет, косвенной адресации через стек тоже нет и т.д.


Last edited by alexcp on 28 Apr 2018 20:27, edited 1 time in total.



28 Apr 2018 19:28
Profile WWW
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Мне кажется, исторически просто так сложилось, что для 8080 нет эффективного С++ компилятора.
На мой взгляд, ассемблеры с развитыми макросредствами предопределили его невостребованность.
Раз уж компиляторы с ВАСИКа всё же существовали.

_________________
iLavr


28 Apr 2018 19:42
Profile
Novelist
User avatar

Joined: 11 Jun 2012 08:30
Posts: 46
Reply with quote
Насколько я понимаю, создавать целиком новый компилятор под конкретный процессор в наши дни необязательно, достаточно написать backend для gcc или llvm и получить набор эффективных компиляторов для разных языков высокого уровня. Комментарий begoon'а при этом остается актуальным - к примеру, отсутствие индексной адресации стека делает неудобным обращение к аргументам функций/процедур и т.п., что делает более громоздким и медленным полученный в результате код. Тем не менее, есть, например, вот такой проект: LLVM backend for Z80.


28 Apr 2018 20:25
Profile WWW
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
alexcp wrote:
Комментарий begoon'а при этом остается актуальным - к примеру, отсутствие индексной адресации стека делает неудобным обращение к аргументам функций/процедур и т.п., что делает более громоздким и медленным полученный в результате код.

А вы вспомните, на чем начинали писать С - мне кажется, ситуация была нисколько не лучше.
С-компиляторы (и ВАСИК-компиляторы) есть для семейства PIC с весьма ограниченными ресурсами
и набором команд.

Вероятно, всё-таки хороший компилятор С для 8080 следует написать отдельно, учитывая его специфику.

_________________
iLavr


28 Apr 2018 21:09
Profile
Novelist
User avatar

Joined: 11 Jun 2012 08:30
Posts: 46
Reply with quote
Lavr wrote:
А вы вспомните, на чем начинали писать С - мне кажется, ситуация была нисколько не лучше.

С начинали писать на PDP, архитектура которой, несмотря на ограниченные ресурсы, существенно богаче архитектуры ранних микропроцессоров. В частности, у PDP много режимов адресации, в том числе стека. То, что все это богатство невозможно было уложить в прокрустово ложе ранних микропроцессоров, и делает эти микропроцессоры неудобными для C/C++ компиляторов (а также для Unix-подобных операционных систем). Offtopic: со временем DEC сделал-таки PDP в виде микропроцессора.

Lavr wrote:
С-компиляторы (и ВАСИК-компиляторы) есть для семейства PIC с весьма ограниченными ресурсами
и набором команд.

Вероятно, всё-таки хороший компилятор С для 8080 следует написать отдельно, учитывая его специфику.
Возможно - спорить не буду. С одной стороны, действительно, специфика архитектура младших PIC (PIC10, PIC12) - например, 8-уровневый аппаратный стек - такова, что сделать GCC backend для нее затруднительно, при этом компиляторы С для PIC давно и успешно существуют. С другой стороны, 8080/8085/Z80 не настолько экзотичен, backend для LLVM вроде бы несколько проще, чем для GCC, его уже даже кто-то пытается написать, а готовая полноценная поддержка C++ чего-нибудь да стоит.

Кстати, пока писал пост, сложил два факта. Во-первых, компилятор языка B, предшественника C, выдавал не двоичный машинный код, а "шитый код", исполняемый на стековой машине. Во-вторых, стековая машина для исполнения "шитого кода" описана в том самом посте в блоге begoon'а, цитату из которого я привел выше.

Ну и, конечно, топикстартер уже пишет на Паскале для РК, пока мы обсуждаем высокие материи :wink: Существует, между прочим, Турбо Паскаль для CP/M. У меня где-то лежит Zeta SBC, на которой он даже работает.


28 Apr 2018 22:07
Profile WWW
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
alexcp wrote:
Lavr wrote:
А вы вспомните, на чем начинали писать С - мне кажется, ситуация была нисколько не лучше.
С начинали писать на PDP, архитектура которой, несмотря на ограниченные ресурсы, существенно богаче архитектуры ранних микропроцессоров.

Мне думается, это не совсем принципиально. Мы в общем-то в топике говорим о компиляторах ЯВУ
для платформ с ограниченными ресурсами
.

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

Но, скажем, та же PDP-8 - ЭВМ с весьма убогими ресурсами даже рядом с 8080, но эффективные
компиляторы с ЯВУ для нее существовали.

Когда я писал на ВАСИК для "Специалиста" мне комплятор С и нафиг был не нужен, мне надо
было ускорить собственные программы, а для этого нужен был компилятор ВАСИК!

Все эти манипуляции со стеком присущи определеным архитектурам процессоров, я почему и сказал,
что развитый ассемблер с макросредствами - очень близок по возможностям к ЯВУ.
Значит эффективный компилятор для 8080 должен быть написан с учетом его особенностей.

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



P.S. И есть вопрос по поводу компилятора более значимый в данный момент - в то время компилятор
был нужен на той же платформе, на которой писали сам код. Сейчас - это скорее всего - кросс-компилятор с ЯВУ.

_________________
iLavr


29 Apr 2018 06:49
Profile
Maniac
User avatar

Joined: 13 Nov 2007 12:09
Posts: 213
Location: Ставрополь
Reply with quote
...к сям отношусь более чем прохладно, но ссылки под компиляторы есть. Продвинутые про них, надеюсь, знают. Осталось только протестировать с современной точки зрения.

Aztec C v1.06D Professional for CP/M-80 http://www.retroarchive.org/cpm/lang/az106d.zip
MI C http://www.retroarchive.org/cpm/lang/mi_c.zip
Mix C v2.0 for CP/M-80 http://www.retroarchive.org/cpm/lang/mix-c.zip
Tiny C http://www.retroarchive.org/cpm/lang/TINY_C.ZIP
The BD Software C Compiler (BDS C) https://www.bdsoft.com/resources/bdsc.html (уже в паблик домене ;) )

А если на Сях мир не повёрнут, то тут ещё много есть, http://www.retroarchive.org/cpm/lang/lang.htm

И да, топик надо перенести в подходящее место.

Про РК-86: уже давно сделали загружаемый шрифт, как в Денди, http://zx-pk.ru/threads/20714-pomechtae ... post713206


29 Apr 2018 07:50
Profile WWW
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
rw6hrm wrote:
...к сям отношусь более чем прохладно, но ссылки под компиляторы есть.

А на компилятор ВАСИК-а для 8080, случаем, нет ссылочки? :wink:

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

_________________
iLavr


29 Apr 2018 11:59
Profile
Maniac
User avatar

Joined: 13 Nov 2007 12:09
Posts: 213
Location: Ставрополь
Reply with quote
Ну так по предпоследней ссылочке находим:

Microsoft BASIC Compiler v5.3 http://www.retroarchive.org/cpm/lang/BASCOM53.ZIP
DRI CBASIC-80 BASIC Compiler http://www.retroarchive.org/cpm/lang/CB80.ZIP
Microsoft BASIC Compiler http://www.retroarchive.org/cpm/lang/BASCOM.ZIP

Не оно?


29 Apr 2018 14:09
Profile WWW
Writer

Joined: 19 Feb 2017 04:46
Posts: 23
Location: 600 км от Москвы
Reply with quote
Post .
По поводу вопроса о том как узнавать адреса меток в INLINE-ассемблере. Чтобы разобраться в вопросе прочитал всю документацию, что имею, просмотрел исходники всех примеров и библиотечных модулей. И похоже, что встроенный в Паскаль МТ+ ассемблер не позволяет без ухишрений встраивать программу содержащую абсолютные адреса переходов. Видимо это однопроходный ассемблер.

Для процессора Z80 это не проблема, т.к там есть JR-команды. На КР580 тоже можно написать перемещаемую программу, для чего достаточно иметь внешнюю подпрограмму возвращающую в регистре HL адрес с которого его вызвали (так устроены SYS-файлы в RK-DOS Е.Седова). Такой метод в данном случае тоже годится, но невыгоден, т.к вместо одной маш.команды перехода тратится более десятка маш.команд (из-за PUSH-POP-ов для HL,DE).

Итак, какие методы в итоге я обнаружил или придумал для использования в ассемблерных INLINE вставках. Обнаружил, что с некоторыми доп.усилиями всё-же можно задавать адреса переходов, т.к ассемблер понимает идентификатор "текущий адрес", который обозначается символом звёздочка (*), а не долларом, как принято в ассемблере. Так, что можно написать строку INLINE ("JZ/*+25); , что в ассемблере эквивалентна JP Z,$+25. Для маленьких ассемблерных вставок это полное решение проблемы.

А вот для больших фрагментов можно замучиться считавши. Тогда уж проще вставлять ассемблерную процедуру готовым заранее транслированным дампом. Для этого, при условии, что INLINE вставка стоит первым оператором процедуры, делаем пробную трансляцию и функцией ADDR(имя_процедуры); выводим на экран адрес с которого в ОЗУ находится данный ассемблерный фрагмент (естественно сама процедура, что этот адрес выводит, должна стоять в самом конце исходника, т.к в окончательном варианте её не будет и при ёё удалении сдвижки адреса ассемблерной процедуры не произойдёт).

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

Далее транслируем на обычном ассемблере этот же фрагмент с полученного адреса и получив дамп, оформляем его как положено для INLINE (это делается простенькой программкой на бейсике полученной простейшей доработкой программы DATAGEN.BAS, что генерит из дампа DATA-строки на бейсике). В итоге, после таких манипуляций получаем готовый к вставке в исходник фрагмент. Но т.к эта процедура странслирована на конкретный адрес, то в программу полезно вставить проверку, т.е в процедуре инициализации функцией ADDR узнавать адрес ассемблерной процедуры и проверять, что ничего не сдвинулось.

Более удобно странслировать ассемблерную вставку обычным ассемблером и рядом с каждой командой перехода вставить EQU-оператор ассемблера вычисляющий офсет от текущего адреса до адреса перехода: OFFS4 EQU MTK-$. Далее в листинге трансляции смотрим эти офсеты и подставляем их в паскалевский текст ассемблерной вставки в виде INLINE("JNZ/*+OFFS4);. Естественно, тут вместо OFFS4 подставляется число из PRN-листинга.

Конечно, для небольших ассемблерных процедур расчёты можно делать вручную. Тогда обычным ассемблером транслируем ассемблерный фрагмент на адрес 0, что даст в листинге абсолютные адреса (от начала) и с помощью HEX-калькулятора считаем для каждой команды перехода относительное смещение от текущего адреса. Но зачем это, если офсеты может считать сам ассемблер?

Что касается CP/M компиляторов Си. Их имеется с десяток. Из них всего несколько - для КР580. Обычно для Z80 используют HiSoft Си, а для КР580 BDS Си. Для КР580 в начале 80-тых были написаны AZTEC и BDS С. Именно они были украдены отечественными "разработчиками" и под другими именами входили в дистрибутив СМ-1800, а позднее использовались и на бытовых ЭВМ.

К сожалению дисководы, а вместе с ними и CP/M стали доступны любителям уже под занавес, в 1993-1995, как раз тогда, когда в страну хлынуло дешёвое западное IBM железо. То что устарело и стало хламом на Западе задешево хлынуло в Россию, отчего 8-ми разрядки сразу же умерли. Этим я хочу сказать, что как Паскаль, так и Си любители программирования просто не успели освоить.

Для ОРИОНА было написано две игры на BDS Си (XenoWorld, Ranger) и чуть большее число игр было написана на самодельном Best-Си. А несколько попыток написания на Си системных программ были лишь частично успешными. Лично я написал на Паскале текстов редактор (10 кб), а на Си нортон (30 кб) и видел ещё несколько аналогичных программ других людей. Обычно использовали BDS С или Турбо-Паскаль.

Выяснилось, что при Си и Паскале с ростом сложности программы объём кода нарастает слишком быстро, делая бессмысленной дальнейшую разработку. Например, в 1996 или 1997 я написал нортон на Си. Сделал лишь часть того, что хотел, а объём кода уже достиг 30 кб. Для нортона это фатально, т.к остаётся совсем мало ОЗУ под буфер открытия окон и, чем меньше дисковый буфер, тем медленнее копирование.

А ведь считается, что Си даёт меньший объём кода, чем Паскаль (но это надо проверить, т.к в МТ Паскале есть возможность исключать из библиотеки ненужные функции). С другой стороны, написание первого нортона на ассемблере заняло у меня более месяца, а на Си всего несколько дней.

На ЯВУ можно писать системные программы только, если есть развитый ROM-BIOS (или заменяющий его консольный драйвер) и для двухбанковой системы. Тогда в одной банке работает программа, а в другой банке размещается экран, мощный цветной оконный консольный драйвер и там же буфер сохранения окон. Тогда программа на ЯВУ не тратит ресурсы на интерфейс.

Например, для открытия окна вызывается функция, которая лишь передаёт управление оконному драйверу. Он сохраняет старое содержимое цветного окна в буфере (причём в банке драйвера, а не программы), очищает цветное окно, выводит двойную рамку с заголовком и настраивает п/п-мму вывода так, что вывод происходит только в окно, т.е координата 0,0 это слева вверху окна (а не экрана). Аналогично, для вывода окна с вертикальным списком из верхней балки меню, также достаточно одной процедуры на ЯВУ, т.к всё остальное делает оконный графический драйвер.

Только с таким двухбанковым железом и мощным графическим ROM-BIOS можно писать системные программы на ЯВУ. Тогда на ЯВУ пишется только логика программы, нет траты ресурсов на интерфейс. А когда ничего такого нет и весь оконный интерфейс тоже приходится писать на Си, объём кода быстро раздувается так, что делает саму программу бессмысленной.

Но всё-же на ЯВУ вполне можно писать несложные программы (например инструментальные) для которых большой объём кода и низкая скорость прогона не критичны. А самым эффективным по скорости и объёму кода ЯВУ является PL/M. Хотя он не сильно упрощает программирование, т.к предельно близок к ассемблеру. PL/M был популярен в 1974-1979, но после появления Паскаля и Си быстро утратил популярность, хотя и в 80-тые использовался для программирования однокристальных контроллеров.

Насчёт компиляторов бейсика. В начале 90-тых были доступны только BASCOM и CBASIC. И на обои не было документации. По счастью BASCOM был совместим с MBASIC, а он имел полный аналог для MSDOS (для которого документации хватало).

А с CBASIC никто так и не сумел разобраться. Хотя есть информация, что он эффективнее. Сейчас на CBASIC полно документации и при желании можно разобраться. Еще есть Tarbell Basic, его хвалили в журналах, но кажется он хуже. Есть также BASIC-E копилятор. И все они для КР580.

BASCOM позволяет очень быстро писать программы, хотя скорость откомпилированной программы растёт всего в 2-3 раза, относительно интерпретатора. А относительно компиляторов Паскаля и СИ результирующий код тоже проигрывает в 1.5 раза по объёму кода и скорости прогона. Но это компенсируется удобством отладки в режиме интерепретации, что ускоряет. Кстати, для Паскаля тоже есть интерпретатор.

Вот почему мелкие инструментальные програмки удобнее писать на бейсике-компиляторе. И лучше на BASCOM, т.к тогда программа без переделок перетранслируется в Quick Basic или Power Basic на IBM PC. Причём Power Basic есть и в варианте для Windows (а не только для MSDOS).

Можно действовать и наоборот. Написать и отладить программу на IBM PC в Power Basic-е, а затем уже для использования в реале на 8-ми разрядке, странслировать её CP/M-компилятором BASCOM.


Last edited by barsik on 29 Apr 2018 15:21, edited 7 times in total.



29 Apr 2018 14:14
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
rw6hrm wrote:
Ну так по предпоследней ссылочке находим:
...
Не оно?

Спасибо за ссылки - надо посмотреть...

Я как-то сам провёл поиск на эту тему (где-то на форуме следы должны остаться),
но ничего подходящего не нашел: либо для Z80, a не 8080, либо сугубо платное,
и в составе каких-то интегрированных пакетов... :-?

_________________
iLavr


29 Apr 2018 14:44
Profile
Maniac
User avatar

Joined: 13 Nov 2007 12:09
Posts: 213
Location: Ставрополь
Reply with quote
barsik wrote:
в другой банке размещается экран, мощный цветной оконный консольный драйвер и там же буфер сохранения окон

barsik wrote:
оконный графический драйвер

...прошло уже тридцать лет с момента сбора мной первого компа (Специалист), но до сих пор так и не понял, зачем:
а) тратить ОЗУ для экрана;
б) использовать графику, ибо же нестандарт для СР/М машин, как я понимаю.
Ну ладно, второй вопрос спорный, посему опустим, но первый... Сделать экран как устройство ввода/вывода дабы не занимать ОЗУ. Отмазки, что типа, IN/OUT занимают больше тактов, ну очень смешны (мне по крайней мере). Это было бы справедливо для игр, но где игры для этих платформ? Тем более графические... А для отрисовки "Нортона" дополнительные такты вообще некритичны. Да, если использовать 8080 на РК-шных частотах (1.77МГц), то мооооожет быть и заметим эти "лишние" такты, и то вряд ли.
Тем более, у нас сейчас не 80-е на дворе, уже можем поставить на экранное "устройство" ещё один полноценный процессор, что разгрузит основной проц от рутинной работы видеовывода. А скорость обмена между основным процессором и видеоблоком может значительно превышать возможности основного устройства. И для ТРА остаётся достаточно места.
Чистое ИМХО. Объясните, чего я могу не понимать. Заранее благодарю ;)


29 Apr 2018 14:51
Profile WWW
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
barsik wrote:
На КР580 тоже можно написать перемещаемую программу, для чего достаточно иметь внешнюю подпрограмму возвращающую в регистре HL адрес с которого его вызвали...

А мы тут на форуме решили уже давненько эту задачу для более жестких условий.

barsik wrote:
А ведь считается, что Си даёт меньший объём кода, чем Паскаль (но это надо проверить...

Для компиляторов х86 - это действительно так. И меньший и более эффективный код делает Си.
Знал я в былые времена одного человека у себя на работе, который это просто проверил.

_________________
iLavr


29 Apr 2018 15:00
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 32 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.