1

Elo :)

Pytanie do koderów którzy napisali sobie asemblery ;)
Wiekszosc dostepnego kodu jaki widzialem (xasm, zooey, mads) uzywa linear sercza do szukania wartosci labeli. (poprawcie jesli sie myle, kod przegladalem dosc pobieznie) Czy nie uzycie haszy wynika z jakiejs mocnej niewydajnosci tej metody akurat
do prostych asemblerów (nie wiem, moze przez alignment i nowoczesne kesze, hasz jest nieoptymalny dla setów danych które używa zwykle asembler jako labele) Czy korzystacie po prostu z faktu ze linear sercza i tablice łatwiej napisać, a zysk prędkości jest niewielki albo żaden na nowoczesnych pecetach. Z pewnych względów ciekawi mnie po prostu jak do tego podeszliscie :)

2

O. Też jestem ciekaw :)
Zasadniczo, nie widziałem jeszcze, żeby kompilacja asma była jakimś problemem wydajnościowym, ale zawsze coś przyspieszyć nie zaszkodzi.
Chociaż wolę, żeby TeBe dodał .USING :)

: 404. Stopka not found

3 Ostatnio edytowany przez epi (2007-07-16 14:22:20)

Oczywiście że liniowe przeszukiwanie jest prostsze i takie też jest w hcaśmie, chociaż w 2.0 przesiadam się na drzewka, gdzie przeszukiwanie jest jeszcze prostsze. :)

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

4

w sumie gdybym dzis mial zaczac pisac zooeya od zera, to schematu struktur (tablice/wektory) bym nie zmienial - zmienila by sie cala reszta :)

5

W xasm 2 było przeszukiwanie liniowe - labelek jest najwyżej kilka tysięcy, wyszukiwań jest najwyżej kilka tysięcy, więc nawet na starym pentiumie to śmiga. Niepotrzebna optymalizacja jest źródłem zła. ;) Taką niepotrzebną optymalizacją było przeszukiwanie binarne mnemoników.

W xasm 3 jest hasz tylko dlatego że jest wbudowany w język D.

https://www.youtube.com/watch?v=jofNR_WkoCE

6

Słowem, nie stoi za tym specjalnie benczmarking, tylko raczej zdrowy rozsadek i wygoda :)
Dzieki chłopcy :D

7

W OMC był hash, bo liniowo było za wolno na ST.

http://www.5oft.pl/

8 Ostatnio edytowany przez laoo/ng (2007-07-16 18:47:48)

ekhem... Mikey pisze YAAAsa (Yet Another Atari Assembler)? ;)

9

tak, zaraz bedzie wiecej assemblerow niz aktywnych koderow :)

10

Jak ma to być asembler na atarkę, zgodny z Quick Assemblerem, wykorzystujący w edytorze bufor w postaci dodatkowej pamięci i wspierający 65816 i pamięć powyżej $ffff to jestem ZA !

11

w mads obliczany jest kod crc32 dla etykiety, jej długość i na tej podstawie trwa poszukiwanie jej w tablicy etykiet, z kolei dla mnemoników, dyrektyw i pseudo rozkazów obliczany jest kod crc16, który jest indeksem do tablicy 64KB przechowującej informacje dekodującą, tak że może być wiele dyrektyw alternatywnych ale ich zdekodowanie zawsze trwa tyle samo

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

12

"nie wiem, moze przez alignment i nowoczesne kesze, hasz jest nieoptymalny dla setów danych które używa zwykle asembler jako labele" napisał mikey wczoraj.

Ło matko!

13

hasz to optymalne rozwiazanie dla maszyn, hera - dla ludzi ;)

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

14 Ostatnio edytowany przez mikey (2007-07-17 11:46:24)

jer: no sso :) prawie po polsku :) nie moja wina że terminologia angielska dominuje w języku programistów :)
zaproponuj jak napisać to zdanie zgodnie z polskim słownikiem, i wtedy możemy licytować które jest śmieszniejsze :)

laoo: no bo wiesz, asemblery to taka nowoczesna rywalizacja, w dobie braku dobrych dem :)

tebe: a jak radzisz sobie z kolizjami? bierzesz je wogole pod uwage?

15

Doskonale rozumiem. Też jednego dłubię! Jak za 10 lat go wypuszczę (a piszę już od Forsaken Love), to zakasuje wszystkie dotychczasowe i pewnie przyszłe też ;)

16

trzymam kciuki :).
ja zooeya zaczalem pisac gdzies w 1999, a wyszedl kiedy wyszedl.

17

zastanawiałem się kiedyś nad kolizjami, jednak żadnej nie udało się sprowokować

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C