[bk0010] unsigned long in pcc

[svo...@gmail.com]

А работает ли в bkunix-овской версии pcc 32-битный integer? unsigned
long?

сво

--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "БК-0010 - первый советский персональный компьютер" - http://groups.google.ru/group/bk0010

[svo...@gmail.com]

Работает наполовину. signed и unsigned, dword iow.

В процессе попыток завести Elm-тянский Petite FatFs на БК выяснил:

-- long может быть аргументом функции, но необходимо явно приводить
тип при каждом вызове, иначе аргумент передается как слово
-- указатель на long может быть аргументом функции
-- long не может быть возвращаемым значением
-- long испытывает трудности, когда он используется как boolean. if
(longvar) сработает более-менее в зависимости от того, как себя
чувствует младшее слово. Надо всегда писать if (longvar != 0L).
-- с тернарными операциями типа long вообще ничего не получилось,
пришлось разбить на if() else

Кроме того:
-- ANSI прототипы функций вроде бы работают, но только если в них нет
определенных через typedef типов
-- в случае с long-ами, прототипы как будто бы не очень помогают.
Возможно, проблема на самом деле в том, что все мои примеры были с
typedef-ами, сил проверить не хватило.
-- переменные байтового размера нельзя использовать для индексации --
используется слово, вторая половина которого как повезет
-- вообще нельзя рассчитывать на то, что компилятор сам правильным
образом выберет тип для выражения. Всегда-всегда надо явно приводить к
нужному типу вручную.

Не рассчитываю на исправления ;) Но, зная все эти ограничения,
компилятором можно пользоваться, поэтому такой список полезно иметь.

сво

[Сергей В.]

Полезный перечень, спасибо.

Так устроен компилятор Джонсона. Его развитие остановилось где-то в
начале 80-х, вероятно. До полной ANSI-шности он не дорос. Впрочем,
компилятор Ритчи еще более дремучий.

К сожалению, GCC давно потерял способность порождать корректный код
для PDP-11.
___
С уважением,
Сергей Вакуленко

[svo...@gmail.com]

> К сожалению, GCC давно потерял способность порождать корректный код
> для PDP-11.

Есть повод надеяться, что скоро мы снова увидим GCC, порождающий
корректный код для PDP-11 ;)

svo

[Сергей В.]

On 18 май, 14:46, <svof...@gmail.com> wrote:
>
> Есть повод надеяться, что скоро мы снова увидим GCC, порождающий
> корректный код для PDP-11 ;)

Неужели кто-то взялся доделать GCC?
Это радостная новость. :)
___
Сергей

[Felix]

Да, взялся :) *на свою голову*

Сделал нормальный вызов функций с использыванием MARK. Сейчас
отлаживаю uclibc порт.

[Сергей В.]

On May 18, 5:47 pm, Felix <felix.laza...@gmail.com> wrote:
> Да, взялся :) *на свою голову*
> Сделал нормальный вызов функций с использыванием MARK. Сейчас
> отлаживаю uclibc порт.

Приветствую, Феликс!

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

В качестве теста можно использовать standalone утилитки и тесты из
проекта bkunix. Например fdfmt, tstsh, tstlsh и другие.

Ну и само ядро bkunix, конечно, неплохо бы запустить.
___
С уважением,

[Felix Lazarev]

Я пока делаю для rt11 target -- потом буду думать насчет bkunix (a.out). На данный момент мне интересен способ создания реальных .sav файлов.
Библиотеки 2 -- одна на основе uclibc , вторая -- зовущая системные функции rt11.

[Leo Broukhis]

2010/5/18 Felix <felix....@gmail.com>:

> Да, взялся :) *на свою голову*
>
> Сделал нормальный вызов функций с использыванием MARK. Сейчас
> отлаживаю uclibc порт.

Много ли корысти в команде MARK? С ней, в конце концов, код не длиннее
ли получается, чем с традиционными CSV/CRET?

Leo

[Felix Lazarev]

я пошёл таким путём --

r0-r3 параметры функции caller saved
r0-r1 результат функции

r4 служебный callee saved
r5 фрейм

если параметр - элипсис или их больше 4х то подключается mark.

при этом я не думаю что код длиннее будет в среднем.

Сдвиги пофиксил. Расцветку регистров пофиксил...

[svo...@gmail.com]

А есть ли цивилизованный способ задать ld конфигурацию памяти, в
частности нужно определить фиксированное положение BSS. Это нужно для
генерации кода, исполняемого из ПЗУ.