czy te scalaki dostępne w wincupl są całkowicie kompatybilne - identyczne
jak gal20v8 i gal16v8 lattice?

do góry

a przy okazji, tu jeszcze nie pytałem, czy Ktoś tu zna metodę mnożenia
zamiast dzielenia liczb? podobno popularne to było za czasów dawnych
procesorów? czy Ktoś może podać jakiś przykład?

do góry

Użytkownik "identifikator: 20040501" <N...@g...pl> napisał w
wiadomości news:i1qb58$f9c$1@mx1.internetia.pl...
>a przy okazji, tu jeszcze nie pytałem, czy Ktoś tu zna metodę mnożenia
>zamiast dzielenia liczb? podobno popularne to było za czasów dawnych
>procesorów? czy Ktoś może podać jakiś przykład?

Zamiast dzielić przez 2, mnożyło się przez 0.5, bo mnożenie
było szybsze. Na tym to polegało.

Podobnie było z potęgowaniem.
Zamiast podnosić X do 11 potęgi mnożyło się 11 razy X przez
siebie. Takie mniej więcej były proporcje na procesorze
8086 6 MHz bez koprocesora.

Jeszcze lepsze proporcje bywały dla 8085.

Pozdrowienia. Krzysztof z Tychów.

do góry

On Fri, 16 Jul 2010 18:49:40 +0200, identifikator: 20040501 wrote:
>czy te scalaki dostępne w wincupl są całkowicie kompatybilne - identyczne
>jak gal20v8 i gal16v8 lattice?

Do celow projektowania tak - tzn dawno dawno temu lattice
gal20v8 spelnial ogolnie przyjety standard gal20v8 i dawal sie
zaprojektowac w Cupl na urzadzenu G20V8.

Czy w kosciach Lattice nie bylo jakis rozszerzen, albo czy nie ma ich
dzis to nie dam glowy. Chyba sa. Ale w wersji podstawowej wystarczy.

Programowanie to osobna kwestia - najlepiej miec programator
obslugujacy kosci danego producenta, i to najlepiej w aktualnej
wersji.

J.

do góry

tego się domyśliłem, ale zupełnie nie rozumiem dlaczego dzielenie przez 10
odpowiada mnożeniu przez 0xcccd? skąd się bierze ta liczba?

do góry

On Fri, 16 Jul 2010 22:20:04 +0200, identifikator: 20040501 wrote:
>tego się domyśliłem, ale zupełnie nie rozumiem dlaczego dzielenie przez 10
>odpowiada mnożeniu przez 0xcccd? skąd się bierze ta liczba?

jak przemnozysz np 15621 [3D05h] przez CCCDh to wyjdzie
30D0D901

bierzemy teraz dwa najstarsze bajty 30D0 i przesuwamy jeszcze o 3 bity
i wychodzi nam 061A czyli .. 1562.

Oczywiscie nie zdziw sie ze 2^19/10 = 0xCCCC.CCC

J.

do góry

> jak przemnozysz np 15621 [3D05h] przez CCCDh to wyjdzie
> 30D0D901
>
> bierzemy teraz dwa najstarsze bajty 30D0 i przesuwamy jeszcze o 3 bity
> i wychodzi nam 061A czyli .. 1562.
>
> Oczywiscie nie zdziw sie ze 2^19/10 = 0xCCCC.CCC

diabelskie sztuczki, próbuję zrozumieć jak na coś takiego można wpaść...

do góry

On Fri, 16 Jul 2010 23:02:39 +0200, identifikator: 20040501 wrote:
>> jak przemnozysz np 15621 [3D05h] przez CCCDh to wyjdzie
>> 30D0D901
>> bierzemy teraz dwa najstarsze bajty 30D0 i przesuwamy jeszcze o 3 bity
>> i wychodzi nam 061A czyli .. 1562.
>> Oczywiscie nie zdziw sie ze 2^19/10 = 0xCCCC.CCC
>
>diabelskie sztuczki, próbuję zrozumieć jak na coś takiego można wpaść...

trywialnie prosto.

Najpierw pomysl dziesietnie: chcemy np podzielic przez 13.
Jest to rownoznaczne z mnozeniem przez 1/13 = 0.0769230769230769..

Oczywiscie my bedziemy sprytni i sobie najpierw pomnozymy przez
76923, a potem podzielimy przez milion.


A binarnie bedziemy chcieli na koncu dzielic np przez 2^17.
Wiec trzeba przemnozyc przez 2^17/13=10082.46..

I juz widac ze lepszy bylby 2^18/13=20164.92.. ~= 20165


J.

do góry

> I juz widac ze lepszy bylby 2^18/13=20164.92.. ~= 20165

dzięki,

do góry