Релиз компилятора SDCC 3.6.0

начальный инициализатор crt0iz, который инициализирует глобальные и статические переменные как 0.

А что, какой-то начальный инициализатор этого не делает?

Делает, но этот не делал.

для MIPS будет?..

Годно!

Помню в университетские годы использовал его что бы на Linux собирать под 8051.

Я на работе на нем собираю для того же 8051

Для MIPS есть gcc, sdcc в первую очередь для тех случаев, куда gcc не втащить.

Автар, что там с отладкой для stm8?

Симулятор хоть есть? Если есть, то как к нему цепляться отладчиком, и поддерживаются ли прерывания?

Я всё никак не решусь обновить и затестить новую версию. По сравнению с 3,5 даже промежуточная 3,5,5 была просто небо в плане пожирания памяти. А ещё надо бы глянуть, починили ли они peephole правила для stm8. А то A |= 1 << 1; и A |= 1 << 7; преобразовывались в одну асм-команду, а если позиция сдвига была [2-6], то мы получали полный фарш из загрузки адреса в индексный регистр, загрузки в аккумулятор и OR с аккумулятором.

Кто пользуется, отписываемся, особенно о привнесённых новшествах.

А хз. Симулятор типа есть, вот только прицепится к нему из отладчика sddb у меня не получилось — всегда запускался симулятор для 8051. Я дебажу по-старинке — светодиодиком.

Печаль. А то на меня выходил разработчик порта для stm8 и предлагал портировать туда BuguRTOS, но без отладчика вообще, это будет БОЛЬ!

А спроси у того разработчика, как отдебажить код. Они используют симулятор для regression tests (как написано на их сайте). Проблема в том, что если работу st-link по протоколу swd отреверсили и добавили в openocd, то SWIM (как, похоже, и всё семейство stm8) оказалось нах никому не нужны ввиду «копеечности» stm32. Насколько мне известно, опенсорс реализация общения с ст-линком по SWIM была сделана только одним человеком и называется stm8flash.

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

Да, там много ещё что не работает. А зашитые были наверно с выставленными options bytes?

Спрашивал, там над бэкэндом работает https://github.com/spth, а над симулятором и отладчиком другие люди.

Алсо, похоже, что он запилил порт atom_threads на sdcc и интерес к бугурту потерял.

Кстати, в среде разработки stvd используется gdb для отладки...
Но там нет поддержки sdcc...
А что, если написать враппер для sdcc, чтобы преобразовывать опции командной сроки какого - нибудь Cosmic или Raisonancе в sdcc???

ОЛОЛО, нужно кастануть сюда кого-нибудь грамотного...

И кстати, на выходе резонанса при использованиии stvd я вижу .elf...

Так что может взлететь...

Да я не знаю, какие пришли. Но, похоже, что да, дело в них

Я, конечно, грамотный как валенок. Но в новости

Добавлен вывод ELF/DWARF для stm8

Разве не это нужно для работы с gdb?

Если стояли lock-bits, тогда нельзя записать новое значение во флеш или еепром, пока не сбросишь их (это произведёт полное стирание чипа). А, если верить написанному на гитхабе, stm8flash не умеет читать/писать локбиты.

А как указать адрес размещения кода и данных при компиляции под z80? Как ограничить адресное пространство доступное для кода?

sdccman.pdf читал? Там есть опции типа

ramon@ramon-desktop:~$ sdcc --help
…
Linker options:
      --code-loc            <nnnn> Code Segment Location
      --code-size           <nnnn> Code Segment size
      --stack-loc           <nnnn> Stack pointer initial value
      --data-loc            <nnnn> Direct data start location
…

Гаспада, а давайте спаём. Есть прекрасная песня и называется она «Пиши на Си».

When I find my code in tons of trouble,
Friends and collegues come to me,
Speaking words of wisdom:
«Write in C».

As the deadline fast approaches,
And bugs are all I can see,
Somewhere, someone whispers:
«Write in C».

Write in C, write in C,
Write in C, write in C,
LISP is dead and buried,
Write in C.

У меня пара «интересных вопросов»,

1. а кто-нибудь пробовал при помощи этой штуки делать что-нибудь с китайскими mp3-плеерами на базе SOC с ядром 8051? Их ведь тыщи, многие имеют lcd, там крутится какая-то своеобразная OS, для многих есть документация на чип - неужто никому неинтересно?

2. А оно может собрать UZI[x]? Тоже занимательная задача, - поиметь «юникс» на девайсе с 8-и битным ядром и собственным lcd (применительно к тем же китайским плеерам).

2. А оно может собрать UZI[x]?

В рассылке часто бывает некий Alan Cox, тебе такой не знаком? Он как раз о z80 и вещает.

https://github.com/EtchedPixels/FUZIX

Тип char теперь беззнаковый по умолчанию.

wtf?

Символьные константы теперь имеют тип int вместо char.

wtf x 2?

Зачем ломать совместимость с подавляющим большинством библиотек??

некий Alan Cox, тебе такой не знаком?

Мне-то знаком, но слышать про этого человека «некий» для меня - очень странно. Хотя, да, кто сейчас вспомнит из молодёжи, что когда он был мейнтейнером онтопика, ядро Linux было просто великолепным... Не то, что сегодня...

https://github.com/EtchedPixels/FUZIX

Это - всё ещё мой любимый Z80.

Меня же интересовал 8051.

P.S. Хотя, как я вижу - там есть TGL6502, можно посмотреть и на него.

А разве есть узикс на архитектуры кроме з80? Да и что спрашивать, возьми и собери, о результатах расскажешь.

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

Ну и ты не уловил шутки юмора в той фразе.

Я знаю Алана как очень грамотного, нудного и очень вьедливого разработчика. При нём ядро Linux было просто вылизано до мелочей. И начало сильно портится после его отставки. Знаю, что он разделяет мою собственную любовь к процессору z80. Он, по моему мнению, - один из двух наиболее адекватных (второй - это уважаемый Сергеей Вакуленко) людей во всём около-юниксовом комьюнити. Это не та персона, шутки о которой я приемлю. По мне - современным разработчикам до него расти и расти.

Я даже не знал, что Кох перестал заниматься ядром. Помню, он был одним из главных мейнтейнеров.

Да и проще надо быть. А то веет снобизмом.

Прекрасно, спасибо.

Прогнал я один свой код для стм8. Генерация кода не поменялась (в моём случае), хотя служебные комментарии в *.lst файлах говорят о том, что логика работы немного изменилась. Теперь компилятор не позволил мне вызвать функцию не указывая параметр (билд 9506 такое позволял). Пришлось явно записать 0, из-за чего итоговая прошивка даже подросла в размерах. Peephole rules практически не менялись, некоторые моменты сгенерированного кода явно избыточны.

Зачем ломать совместимость с подавляющим большинством библиотек??

Вообще-то, «подавляющее большинство библиотек» как раз подразумевает тип int для символьных констант, ибо так написано в стандарте C. И для информации:

vp:/tmp$ cat a.c 
#include <stdio.h>
int main () { printf("%u\n", sizeof '+'); }
vp:/tmp$ gcc -O2 a.c
vp:/tmp$ ./a.out 
4
vp:/tmp$ gcc --version |head -1
gcc (GCC) 4.8.5 20150611 (prerelease)

ибо так написано в стандарте C

Во всех стандартах?

Да, как рах дело в них, похоже. Но это очень нужная вещь, требуемая для этих мк, без них никуда.

Тип char теперь беззнаковый по умолчанию.

А теперь все старые проекты надо исправлять на signed char?

что-нибудь с китайскими mp3-плеерами на базе SOC с ядром 8051?

И как ты будешь туда хотя бы заливать прошивку? Вот есть wifi rtl8187b с SoC, где 8051. Нигде в открытом драйвере даже не упоминается firmware или подобное. eeprom снаружи содержит пару конфигурационных байт, значит пзу с firmware внутри soc. Предполагаю, какие-то команды переводят SoC в режим, когда можно заменить прошивку, но как их реально узнать, кроме перебора?

ps Хотя, по-моему, правильней называть rtl8187b не soc, а asic. Или, если есть cu, то это уже soc?

Ты подтвердил новость, но сам так и не перешёл по ссылке? Есть опция --fsigned-char

Согласен. Ещё и еепром нельзя считать/записать, если у тебя стлинк_1. А именно такой стоит в дискавери. Я поражаюсь компании СТМ - чипы по цене песка, но сами же урезают возможность их использования. Видать, их интересуют только крупные заказчики, любители их не волнуют. Могли бы нанять пару человек для допила sdcc, но нет, мы лучше с космиком добазаримся, чтоб нам сделали меньше ограничений в специальной версии. Кст, Филипп делал сравнение компиляторов для stm8.

Этим компилятором собирается FUZIX. Ура.

Зачем это нужно если есть Visual Studio?

Во всех стандартах?

Насколько мне известно, по крайней мере в C89 и C99. Но сами стандарты я не читал, информация получена из третьих источников. Кажется, даже у Страуструпа что-то было на эту тему в его «Язык программирования С++».

Отличный вопрос: зачем нужен компилятор, если есть среда разработки? Анонимус уже не тот. :(

Кажется, даже у Страуструпа что-то было на эту тему в его «Язык программирования С++».

Причем здесь С++ если речь о С?

Отличный вопрос: зачем нужен компилятор, если есть среда разработки? Анонимус уже не тот. :(

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

Если есть человек, который пишет на чистом Си. Рекомендую редакторы vim и nano. Nano простой, и это гут! Vim позволяет не выходя из программы дать команду bash-у, чтобы исходный файл скомпилировался.

Vim и nano — ваши друзья!

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

которые умеют компилировать для z80?