🚀 go-pugleaf

On 18/04/2016 11:49, zeus wrote:
 > Muszę porzeźbić trochę w dos-ie.
> Czy ktoś mógłby łopatologicznie wyjaśnić różnicę.
> Bo ja na razie poza
> calloc(x, size)
> i
> malloc(x * size)
> nie widzę.

różnica ta sama co na każdej innej platformie: calloc() gwarantuje 
wyzerowanie pamięci, a to czasem może być przydatne (ale kosztuje więcej 
czasu CPU).

ewentualną zaletą może być to, że z calloc() nie musisz martwić się o to 
czy wynik mnożenia x*size aby nie przekroczy inta (czyt. 64K w przypadku 
real mode), ale to zaleta tylko jeśli x i size są intami, i tylko w 
modelu huge (bo w innych tak czy inaczej calloc polegnie na >64K).

Mateusz

> ewentualną zaletą może być to, że z calloc() nie musisz martwić się o to
> czy wynik mnożenia x*size aby nie przekroczy inta (czyt. 64K w przypadku
> real mode), ale to zaleta tylko jeśli x i size są intami, i tylko w
> modelu huge (bo w innych tak czy inaczej calloc polegnie na >64K).
>
> Mateusz

Wielkie dzięki
mam spore tablice 9000 * 4 * double
i zastanawiałem co wybrać, teraz mam (huge*)farcalloc.
Dzięki za pomoc w zrozumieniu działania.

Pozdrawiam
S.Z.

swoją drogą, wygląda na to że aplikacja nad którą pracujesz wykazuje 
spore potrzeby pamięci... czy jest jakiś powód dla którego działasz w 
real mode? model huge mało kiedy stanowi panaceum - tak czy inaczej 
musisz zmieścić się z wszystkim w 640K (wliczając w to system 
operacyjny, ewentualne sterowniki i kod aplikacji). no chyba że celujesz 
w późniejsze użycie XMS, ale to sprowadza się do napisania własnego 
menedżera pamięci i kombinowanie z ciągłym przesuwaniem okienka 64K by 
dojść do swoich danych.

przejście na protected mode dużo uprości zarządzanie pamięcią - np. 
prosty malloc(1024*1024) przestanie być problemem. no i zyskujesz na 
bezpieczeństwie - znika ryzyko że pomyłkowy zapis do pamięci zabije 
system, lub wręcz spowoduje zniknięcie danych z dysków...

no chyba że ma to działać na sprzęcie klasy XT, wtedy protected mode 
oczywiście nie wchodzi w grę.

Mateusz



On 18/04/2016 12:59, zeus wrote:
>> ewentualną zaletą może być to, że z calloc() nie musisz martwić się o to
>> czy wynik mnożenia x*size aby nie przekroczy inta (czyt. 64K w przypadku
>> real mode), ale to zaleta tylko jeśli x i size są intami, i tylko w
>> modelu huge (bo w innych tak czy inaczej calloc polegnie na >64K).
>>
>> Mateusz
>
> Wielkie dzięki
> mam spore tablice 9000 * 4 * double
> i zastanawiałem co wybrać, teraz mam (huge*)farcalloc.
> Dzięki za pomoc w zrozumieniu działania.
>
> Pozdrawiam
> S.Z.

W dniu 2016-04-18 o 13:29, Mateusz Viste pisze:
> swoją drogą, wygląda na to że aplikacja nad którą pracujesz wykazuje
> spore potrzeby pamięci... czy jest jakiś powód dla którego działasz w
> real mode? model huge mało kiedy stanowi panaceum - tak czy inaczej
> musisz zmieścić się z wszystkim w 640K (wliczając w to system
> operacyjny, ewentualne sterowniki i kod aplikacji). no chyba że celujesz
> w późniejsze użycie XMS, ale to sprowadza się do napisania własnego
> menedżera pamięci i kombinowanie z ciągłym przesuwaniem okienka 64K by
> dojść do swoich danych.
>
> przejście na protected mode dużo uprości zarządzanie pamięcią - np.
> prosty malloc(1024*1024) przestanie być problemem. no i zyskujesz na
> bezpieczeństwie - znika ryzyko że pomyłkowy zapis do pamięci zabije
> system, lub wręcz spowoduje zniknięcie danych z dysków...

Na razie się mieszczę na oparach (dzięki za pomysł z XMS). Działa na tym 
dalmierz satelitarny (od 1990r).
Ta tablica zbiera wyniki i to jest max co się jeszcze zmieści.
A jak skończy pomiar zwala to do pliku i tyle (w trakcie pomiaru nie da 
rady pakować do pliku - program jest dość mocno zajęty).
Napisanie tego pod inny sys wiązało by się z nową elektroniką i 
mechaniką. A ja nie jestem taki mocny (próby pod win nie powiodły się - 
dostęp do portów i opóźnienia). Nowy dalmierz to są gigantyczne koszty 
liczone w milionach $.

Pozdrawiam
S.Z.

On 2016-04-18 15:09, zeus wrote:
> Napisanie tego pod inny sys wiązało by się z nową elektroniką i
> mechaniką.

A dlaczego?

W dniu 2016-04-18 o 15:09, zeus pisze:
> W dniu 2016-04-18 o 13:29, Mateusz Viste pisze:
>> przejście na protected mode dużo uprości zarządzanie pamięcią - np.
>> prosty malloc(1024*1024) przestanie być problemem. no i zyskujesz na
>> bezpieczeństwie - znika ryzyko że pomyłkowy zapis do pamięci zabije
>> system, lub wręcz spowoduje zniknięcie danych z dysków...
>
> Ta tablica zbiera wyniki i to jest max co się jeszcze zmieści.
> A jak skończy pomiar zwala to do pliku i tyle (w trakcie pomiaru nie da
> rady pakować do pliku - program jest dość mocno zajęty).
> Napisanie tego pod inny sys wiązało by się z nową elektroniką i
> mechaniką. A ja nie jestem taki mocny (próby pod win nie powiodły się -
> dostęp do portów i opóźnienia).

Ale propozycja była zmiany trybu na chroniopny nadal w DOS-ie, a nie 
zmiany systemu. Nadal masz szybki dostęp do portów, czy z czego tam 
korzystasz, bo żadne inne procesy się nie wcinają, a RAM-u 
wykorzystujesz do 4 GB.

DJGPP albo Watcom działały bardzo sprawnie. Oba stare, ale jak piszesz w 
trybie rzeczywistym i tak masz stary kompilator zapewne ;)

Pozdrawiam

On 18/04/2016 19:41, keiichi wrote:
> DJGPP albo Watcom działały bardzo sprawnie.

tzn. już nie działają? ja obu do tej pory używam i bardzo sobie chwalę.

> Oba stare, (...)

kolega zdaje się nie być na bieżąco w temacie. co jak co, ale DJGPP 
ciężko nazwać "starym". ;-)

Mateusz

> DJGPP albo Watcom działały bardzo sprawnie. Oba stare, ale jak
> piszesz w trybie rzeczywistym i tak masz stary kompilator zapewne ;)

DJGPP nie jest "stary".

C:\>gcc -v
Using built-in specs.
COLLECT_GCC=c:/dj/bin/gcc.exe
COLLECT_LTO_WRAPPER=c:/dj/bin/../libexec/gcc/djgpp/5.30/lto-wrapper.exe
Target: djgpp
Configured with: /gcc-5.30/configure 
djgpp --disable-werror --enable-languages=c,c++,fortran,objc,ob
j-c++,ada --enable-libquadmath-support --enable-lto
Thread model: single
gcc version 5.3.0 (GCC)


-- 
Wiktor S.

> DJGPP albo Watcom działały bardzo sprawnie. Oba stare, ale jak piszesz w
> trybie rzeczywistym i tak masz stary kompilator zapewne ;)

BC 5.2

Napisane programy były w BC 3.1. Pod DJGPP za dużo przeróbek(kiedyś 
próbowałem -> kazano mi zostawić a teraz za bardzo mi się nie chce). 
Teraz musiałem trochę pozmieniać w programie. No i trzeba sobie trochę 
przypomnieć jak takie rzeczy się robiło.

Pozdrawiam
S.Z.

> DJGPP albo Watcom działały bardzo sprawnie. Oba stare, ale jak piszesz w
> trybie rzeczywistym i tak masz stary kompilator zapewne ;)

Czy może ktoś przesłać mi na priwa przykład jak się przenieść z grafiką 
z BC (egavga.bgi) na DJGPP. Nie mogę sobie z tym poradzić.

Pozdrawiam
S.Z.

On Mon, 18 Apr 2016 15:09:06 +0200, zeus <zeus@cbk.poznan.pl> wrote:
> dostęp do portów i opóźnienia). Nowy dalmierz to są gigantyczne 
koszty

Dostęp do portów załatwia wstawka w Asemblerze. Plus ustawienie 
priorytetu na maksa. Pomiar czasu... TSC jeżeli jest. Ew. mmtimers. 
Jako kompilator GCC...  Have fun.

> Dostęp do portów załatwia wstawka w Asemblerze. Plus ustawienie
> priorytetu na maksa. Pomiar czasu... TSC jeżeli jest. Ew. mmtimers. Jako
> kompilator GCC...  Have fun.

Jak już pisałem ja nie jestem taki mocny. 20 lat temu to asemblerem 
dałbym radę pod MERA400 ale pod PC brak doświadczenia. Odrazu było 
"C"Borlanda i drobne wstawki do obsługi myszy.
A potem nikomu nie chce się wracać od wygody...

Pozdrawiam
S.Z.

On 19/04/2016 08:26, zeus wrote:
> Czy może ktoś przesłać mi na priwa przykład jak się przenieść z grafiką
> z BC (egavga.bgi) na DJGPP. Nie mogę sobie z tym poradzić.

nie ma czegoś takiego jak "grafika w DJGPP". DJGPP nie oferuje żadnej 
wbudowanej/niestandardowej biblioteki graficznej (i po mojemu dobrze).

tak samo jak na innych platformach należy wybrać sobie jakąś 
specjalizowaną bibliotekę do tego (typu SDL, QT, GTK, itp), tak samo 
jest tu. mogę tylko polecić Allegro (w wersji 4.x, bo potem porzucili 
target DOSowy). tutaj przykład który popełniłem jakiś czas temu:
https://sourceforge.net/p/zboy/code/HEAD/tree/trunk/drv_alle.c

alternatywnie możesz także kombinować z samodzielnym rysowaniem do 
pamięci VGA, ale to już trochę wyższa poprzeczka. tutaj przykład mojej 
'biblioteki' do trybów 13h i 04h:
https://sourceforge.net/p/sudoku86/code/HEAD/tree/trunk/video.c

powyższy przykład jest dla real mode. pod DJGPP należałoby pozmieniać 
kilka wywołań, tak jak to opisane tu:
http://www.delorie.com/djgpp/doc/ug/graphics/vga.html

Mateusz

  tutaj przykład który popełniłem jakiś czas temu:
> https://sourceforge.net/p/zboy/code/HEAD/tree/trunk/drv_alle.c
> https://sourceforge.net/p/sudoku86/code/HEAD/tree/trunk/video.c
> http://www.delorie.com/djgpp/doc/ug/graphics/vga.html

Wielkie dzięki
Pozdrawiam
S.Z.

On Tue, 19 Apr 2016 09:20:04 +0200, zeus <zeus@cbk.poznan.pl> wrote:
> Jak już pisałem ja nie jestem taki mocny. 20 lat temu to asemblerem

Nie potrzebujesz assemblera. Wystarczą ci dwie funkcje w C - jedna z 
in druga z out do portu. Pięć minut z Google. W każdej jedna linijka 
asm(....)

W dniu 2016-04-18 o 20:17, Mateusz Viste pisze:
> On 18/04/2016 19:41, keiichi wrote:
>> DJGPP albo Watcom działały bardzo sprawnie.
>
> tzn. już nie działają? ja obu do tej pory używam i bardzo sobie chwalę.

Nie wiem, dawno nie używałem, dlatego mówię że działały. Nie zaprzeczam, 
że działają nadal sprawnie.

>> Oba stare, (...)
>
> kolega zdaje się nie być na bieżąco w temacie. co jak co, ale DJGPP
> ciężko nazwać "starym". ;-)

Dobra, faktycznie, nie sprawdziłem, przyznaję się do bezpodstawnych 
wniosków. Ale nie bijcie. Zaglądałem kilka razy na stronę, ale nie 
analizowałem pakietów, a tu niespodzianka - gcc bardzo na czasie.

Pozdrawiam