Witam

Użyłem w końcu sdcc 8051, ale wcześniej próbowałem w Keil uVision 8051
(v5.25.3.0 - najnowsza):
-------------------------------
#include <REG2051.H>

unsigned char x;

void main (void) {

x = 1;
while(1);

}
-------------------------------
Po kompilacji wychodzi plik BIN ponad 2kB, nie mieści się w AT89C2051
(ustawiony jako device w opcjach). Na początku są 2-3 bajty, później
około 2k zer, albo 0xFF (zależnie który konwerter HEX-BIN) i dopiero na
końcu kilkadziesiąt bajtów programu. Próbowałem różnych ustawień,
optymalizacji, model: small do 2kB, itd. Czy Keil tak ma czy ja coś źle
robię?

P.S. Rady o zastosowaniu innego procka - niepotrzebne.

do góry

W dniu 22.08.2018 o 07:47, Karol Ryfer pisze:
> Witam
>
> Użyłem w końcu sdcc 8051, ale wcześniej próbowałem w Keil uVision 8051
> (v5.25.3.0 - najnowsza):

> Po kompilacji wychodzi plik BIN ponad 2kB, nie mieści się w AT89C2051
> (ustawiony jako device w opcjach). Na początku są 2-3 bajty, później
> około 2k zer, albo 0xFF (zależnie który konwerter HEX-BIN) i dopiero na
> końcu kilkadziesiąt bajtów programu. Próbowałem różnych ustawień,
> optymalizacji, model: small do 2kB, itd. Czy Keil tak ma czy ja coś źle
> robię?

Celowe działanie Keila, żebyś wersji demo nie używał do małych procków.
Jak kupisz pełną wersję, to przestanie się tak zachowywać.

do góry

On Wed, 22 Aug 2018 08:09:41 +0200, Zbych <a...@o...pl> wrote:
> Celowe działanie Keila, żebyś wersji demo nie używał do małych
> procków.

Ale co to za utrudnienie, jak wyrzucenie rozpychaczy z hexa jest
banalne? Gorzej gdyby generował celowo rozepchniety (ale działający
poprawnie) kod wynikowy, jak to robią toolsy mchp.

--
Marek

do góry

W dniu 22.08.2018 o 08:46, Marek pisze:
> On Wed, 22 Aug 2018 08:09:41 +0200, Zbych <a...@o...pl> wrote:
>> Celowe działanie Keila, żebyś wersji demo nie używał do małych procków.
>
> Ale co to za utrudnienie, jak wyrzucenie rozpychaczy z hexa jest
> banalne?

Kod dla 51 nie jest relokowalny (choćby call ma adres bezpośredni) a
wykorzystanie zawijania adresu do 2kB raczej się nie uda, bo kompilator
nie wstawia tablicy wektorów do tego segmentu przesuniętego o 2KB, tylko
do segmentu zaczynającego się od 0, więc nie możesz po prostu przesunąć
kodu o równe 2kB, tylko o (2kB - rozmiar tablicy wektorów).

do góry

Zbych <a...@o...pl> wrote:

> Kod dla 51 nie jest relokowalny (choćby call ma adres bezpośredni) a
> wykorzystanie zawijania adresu do 2kB raczej się nie uda, bo kompilator
> nie wstawia tablicy wektorów do tego segmentu przesuniętego o 2KB, tylko
> do segmentu zaczynającego się od 0, więc nie możesz po prostu przesunąć
> kodu o równe 2kB, tylko o (2kB - rozmiar tablicy wektorów).

Pytanie czy nie ma narzędzi, które przelecą ten kod i go zrelokują. Takie
coś nie jest trudne do napisania (choć pracochłonne).

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

W dniu 22.08.2018 o 13:13, Queequeg pisze:
> Zbych <a...@o...pl> wrote:
>
>> Kod dla 51 nie jest relokowalny (choćby call ma adres bezpośredni) a
>> wykorzystanie zawijania adresu do 2kB raczej się nie uda, bo kompilator
>> nie wstawia tablicy wektorów do tego segmentu przesuniętego o 2KB, tylko
>> do segmentu zaczynającego się od 0, więc nie możesz po prostu przesunąć
>> kodu o równe 2kB, tylko o (2kB - rozmiar tablicy wektorów).
>
> Pytanie czy nie ma narzędzi, które przelecą ten kod i go zrelokują. Takie
> coś nie jest trudne do napisania (choć pracochłonne).

Będziesz miał problem, żeby odróżnić stałe zapisane w ROM od prawdziwych
rozkazów. Ale jak jesteś kustoszem z zacięciem, to czemu nie.

do góry

Zbych <a...@o...pl> wrote:

>>> Kod dla 51 nie jest relokowalny (choćby call ma adres bezpośredni) a
>>> wykorzystanie zawijania adresu do 2kB raczej się nie uda, bo kompilator
>>> nie wstawia tablicy wektorów do tego segmentu przesuniętego o 2KB, tylko
>>> do segmentu zaczynającego się od 0, więc nie możesz po prostu przesunąć
>>> kodu o równe 2kB, tylko o (2kB - rozmiar tablicy wektorów).
>>
>> Pytanie czy nie ma narzędzi, które przelecą ten kod i go zrelokują. Takie
>> coś nie jest trudne do napisania (choć pracochłonne).
>
> Będziesz miał problem, żeby odróżnić stałe zapisane w ROM od prawdziwych
> rozkazów. Ale jak jesteś kustoszem z zacięciem, to czemu nie.

Ja nie jestem, to Karol ma potrzebę :)

Co do odróżnienia stałych, to pytanie, gdzie te stałe są zapisane. Są
wymieszane z kodem? Są zaraz za kodem i oddziela je jedynie flow programu,
który nigdy ich nie wykonuje (co będzie trudne do wykrycia, jeśli CPU
wspiera skoki pod adres podany w rejestrze a nie bezpośrednie)?

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

Marek wrote:

> Ale co to za utrudnienie, jak wyrzucenie rozpychaczy z hexa jest
> banalne? Gorzej gdyby generował celowo rozepchniety (ale działający
> poprawnie) kod wynikowy, jak to robią toolsy mchp.

Staracie się o posadę w Muzeum Techniki, czy co?

Pozdrawiam, Piotr

do góry

On 2018-08-22 22:19, Piotr Wyderski wrote:
> Marek wrote:
>
>> Ale co to za utrudnienie, jak wyrzucenie rozpychaczy z hexa jest
>> banalne? Gorzej gdyby generował celowo rozepchniety (ale działający
>> poprawnie) kod wynikowy, jak to robią toolsy mchp.
>
> Staracie się o posadę w Muzeum Techniki, czy co?
>
Byle nie zostać opiekunem sikieradek!
https://www.youtube.com/watch?v=sKYaWtsGQac&ab_chann
el=KabaRetyHD

Włodek

do góry

> Celowe działanie Keila, żebyś wersji demo nie używał do małych procków.
> Jak kupisz pełną wersję, to przestanie się tak zachowywać.


Dzięki

do góry