[yes 5]

ну кроме скорости может быть надежность - то есть эта память всегда есть и всегда есть место, то есть стек оверфлоу не происходит.

я не понимаю, зачем это может понадобится в 8-ми битнике (а с мико8 мне лень разбираться), но в 32-х битных, с юзерским стеком могут быть проблемы (например, выравнивание), или же в многозадачке, когда каждая задача имеет очень маленький стек, резервировать память в стеке каждой задаче для прерывания - расход памяти.

вобщем причин может быть много, конкретно для мико8 - не знаю

[sonycman 0]

Да, после красивого ARM кода компиляторов под кортексы местный GNUтый компилер выглядит весьма деревянным.

 

А именно - работа с регистром страниц памяти.

Если размер памяти scratchpad (то есть оперативки) не превышает 256 байт - то есть одной странички - то всё в порядке, переключать page регистр не надо.

Но если больше 256 байт - то появляется page регистр(ы), состояние которого компилятором не отслеживается, а просто тупо переписывается каждый раз при обращении к памяти:

    movi    r13,_hi(16)
    export    r20,_lo(16)
    movi    r13,_hi(17)
    export    r22,_lo(17)
    movi    r13,_hi(17)
    export    r14,_lo(17)
    movi    r13,_hi(11)
    import    r0,_lo(11)

r13 - регистр страницы.

Совершенно лишние три команды, упорно запихивающие одно и то же значение...

Оптимизация Os.

 

Это здорово увеличивает размер кода, что вообще-то противоречит самой идее компактного процессора.

 

Неужели так трудно было допилить компилер? :01:

 

ЗЫ: что-то уже хочется плисину с нормальным хардовым армом, для которого можно писать оптимальный код в кейле или иаре, а не париться с недопроцессорами и такими-же недокомпиляторами для них.

Мелкие кортексы есть у Microsemi, но их или не достать, или дорогие, собаки... :(

[sonycman 0]

С другой стороны сегодня посмотрел по тактам выполнение программы и был приятно удивлён весьма шустрым выполнением команд.

Основная масса выполняется за 2 такта, включая команды переходов и даже вызовов подпрограмм(!).

Очень удивился насчёт переходов - вот что значит простой процессор :)

 

Команды по работе с ОЗУ выполняются 3 такта, тоже достаточно быстро.

 

И только обращение к периферии (export/import) идёт 5 тактов.

 

В общем - очень шустрый восьмибитник :)

Ему бы ещё вылизанный компилятор...

[Doka 1]

коль скоро в этой теме собрались корифеи lm8, спрошу и я:

 

1. вот распаковал я rpm'ку diamond_3_8-lm_x64-115-3-x86_64-linux.rpm

нашел папку с тулчейнами под lm8 & lm32, а сам lm8 (verilog) нигде не лежит в дистрибутиве?

только из красивого GUI генерится? и что генерится - нетлист или захардкоженный RTL?

 

2. кто-то пробовал этот lm8 синтезить под отличные от поддерживаемых diamond семейства - например на кристалы серии iCE или того хуже под Xilinx?

 

 

В общем - очень шустрый восьмибитник :)

Ему бы ещё вылизанный компилятор...

FYI, компилятор (тулчейн) похоже не обновлялся с октября 2011 года(((

 

[faa 4]

FYI, компилятор (тулчейн) похоже не обновлялся с октября 2011 года(((

 

Крайний gcc-4.4.3 (с патчем для lm8) от января 2010 года.

Свежее не видел.

 

Для lm32 можно собрать посвежее. Работает.

Можно посмотреть на ohwr.org в "Белом кролике" - церновцы lm32 используют в свитче и оконечниках, причем на Xilinx-е.

 

[gk2 0]

В 3.6 было здесь:

 

/usr/local/latticemicosystem/3.6_x64/lm/micosystem/components/lm8/rtl/

[Doka 1]

Для lm32 можно собрать посвежее. Работает.

не, интересует только Mico8, как замена хитрому FSM

lm32 - это как из пушки по воробьям.

 

 

 

В 3.6 было здесь:

 

/usr/local/latticemicosystem/3.6_x64/lm/micosystem/components/lm8/rtl/

 

спасибо, нашёл.

в 3.8 тут:

 

latticemicosystem/3.8_x64/micosystem/components/lm8/rtl/verilog/