flat assembler
Message board for the users of flat assembler.

Index > Main > FASMLIB (FASM Standard Library Project)

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i am thinking how to implement it internally without too much overhead (we don't want to end up with something like windoze API with thousands arguments and flags you never use). I think it will be separate module, some lzssfile or whatever.

Is that your code? I tend to comment all FASMLIB code well, and i don't know much about LZSS.

Bitstreams must wait until we implement streams. I am still not sure how to implement them, whether merge file and stream (which can sometime be unwanted generality), or make another module for streams, thus having 2 ways to access files (like in C lib). Right now i prefer second approach, but i am afraid if it wouldn't end up with something like C's std libs, you know what i mean.
Post 23 Nov 2005, 09:18
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
Code was written by me, but it is based on C snippet from here: http://programmersheaven.com/zone5/cat858/2260.htm (Although it is in Assembler section, it is all written in C). Allegro routines are based on this one too. However with bitstreams my code can achieve better compression ratio (because dictionary isn't limited to 2^12 bytes, if you know what I mean Wink).
Post 23 Nov 2005, 10:00
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
so bitstreams are required for your lzss library to run? What dictionary size do you use?
Post 23 Nov 2005, 10:57
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
Yes, they are.
Dictionary size can be adjusted in lzss.inc file:
Code:
LZSS_COUNT_BITS      = 4
LZSS_OFFSET_BITS     = 12    

This are settings in version that I posted. Dictionary size is 2^LZSS_OFFSET_BITS, so it will be 4096 bytes in this case. One "entry" fits in 2 bytes (16 bits). Different files need different settings to achieve better compression ratio, but generally you can rise LZSS_OFFSET_BITS to 13 to get optimal settings (and maybe LZSS_COUNT_BITS to 5). Of course files cannot be packed and unpacked with different settings - that's most important drawback of my library.
Post 23 Nov 2005, 11:12
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i believe it could take a rewrite, i believe these can act as variables.

Are ratios at different sizes so significant? Wouldn't it be better to use always 12/4 and thus get rid of need for bitstream? because i don't like tying modules too much, i want them to be a lot independent, so we won't end with 30kb Hello World.
Post 23 Nov 2005, 14:07
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
It again depends on file type Wink
And to get rid of bitstreams you would have to do more changes - each "entry" is prefixed by one bit flag telling if it is a "direct (unpacked) byte" or dictionary entry. And sizes lower than 12/4 will give horrible ratio.
So why don't you treat bitstreams as a part of LZSS library? If user wants to use compression, then he proably won't main this few bytes of code.
Your "hello world" app won't grow at all, because it doesn't need compression routines Smile.
Post 23 Nov 2005, 14:27
View user's profile Send private message Visit poster's website Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
cool idea,

nice set of procedures / functions in standard library,

i whould have a little question, whould it be hard to implement fasm to get used functions from libraries, include it into compiled executable, so unused functions not get included?

as a feature added like : switch: skip_unused_procs_from_include_files

this could speed up program writing a bit, so asm ers does not have to find, cut paste functions, only look at the TOC (table of contents) parameters, results
Post 23 Nov 2005, 14:48
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i was thinking about using 8 flags packed in one byte and then 8 entries.

That thing with bitstreams could work, it's really extremely easy to implement bitstream.

about hello world - i was thinking about something like - make string -> allocate memory for it -> pass to complex printf-like thing -> pass to write stream -> pass to write console -> pass to OS. (little pesimistic, i know Smile )
Post 23 Nov 2005, 14:51
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
vid wrote:
i was thinking about using 8 flags packed in one byte and then 8 entries.

that is exactly how it works in oryginal code Wink But, why not to have something better than that?
Post 23 Nov 2005, 15:16
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Noooooo way - I don't want to hear about 30KB "Hello World!". This means you put everything in just in case. Don't do that. We have MATCH and macros and we can make conditional inclusion - we don't need to have all that bloat. FASM is so fast that you barely notice the filtering that its going through under the core.
Post 23 Nov 2005, 16:27
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
decard: i know, i've read it already. okay, i seems really easy to implement so it's okay. but i'll have to play with that... later

madis: don't worry, i'm here to prevent that!!! :]
Post 23 Nov 2005, 18:15
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
[EDIT] Out of date, see next post[/EDIT]
One problem: Some non-strlib routines will take strings (null-terminated) as arguments. But this will require some kind of calling str.ptr before to use strings from strlib as arguments. I see 3 solutions:

1. User must always call str.ptr

2. String library will be "automaticaly" included. Problem here is this tends to 30kb Hello world problem, and user also has to initialize it. Every proc taking strings will automatically call str.ptr on that argument.

3. This solution is improved solution #2, but is little unnatural: strlib is always included, but doesn't have to be initialized. str.ptr will check if strlib is initialized, if it isn't it will just return argument in eax, if it is it will act normally. You still have to always-include strlib, but you don't need to initialize it (and thus most of procs from there won't be really included then).

So what do we want: smarter but little overbloating library easier to use, or hardcore plain simple harder to use one?

I vote for solution #3. Overbloat in this case isn't notable, effect is very big. Consistency of strlib is little damaged, but i would make this one an exception... effect is really great.
Post 23 Nov 2005, 22:52
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
grrrrrrr, that won't work. I think strlib has to be "always" initialized. I was planning that things like input procedures will use it by default, so you don't have to pass buffer and it's size thus limiting input size.

Anyway I use same approach for strlib using mem module. So "str.ptr" will stay as i described it in previous post for extreme cases when user doesn't want strlib (and thus everything what uses it, like input, conversion to string etc,etc). Procs which wants will use it and throw error if it isn't initialized.

decard: i saw that many routines ignored zero arguments as string handles, instead of treating them as error. Does someone use this behavior. IMHO it was bad, because some procs which should return string handle returned 0 on error, and so you can't say "string handle 0 means ignore".

PS: I have about half of strlib done (not of whole fresh's strlib, i removed few things like conversions or URL encoding...). I've uploaded newest version, with some changes in guide.txt as well.
Post 23 Nov 2005, 23:16
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
You're right. I've been doing some fixes about that in latest release.
Post 24 Nov 2005, 07:44
View user's profile Send private message Visit poster's website Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
I once wrote LZW algorithm but in MASM. Unforutnately I knew nothing about optmization then, so it compresses really slow, but worked good Smile
Post 24 Nov 2005, 20:29
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
I wrote my program myself, just optimization is based on C source that I provieded link to.
Post 24 Nov 2005, 20:36
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
decard wrote:
Do you want every function to report error in CF?


Sorry, i missed this post.

Yes, every single procedure will return errors in CF. I find it much easier to use, for us assembly programmers, than any other option.
Post 29 Nov 2005, 17:45
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
OK so let's see how it will work.
Post 29 Nov 2005, 18:06
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
btw, things like str.pos returns with this:
Code:
;==============================================================================================;
; str.pos
; desc: find position of string inside another string
; args: string - handle or pointer to string
;       pattern - handle or pointer to pattern to search for in string
; ret: CF set on error, otherwise
;      ZF set if pattern doesn't occur inside string, otherwise
;      eax = offset of first occurence of pattern inside string
;==============================================================================================;
    

think how will this be solved in HLL stdcall. Only "standard" way i can think of is something like:
Code:
invoke StrCmp, [str1], [str2]
push eax
invoke GetLastError
cmp eax,0
jnz .error
pop eax
cmp eax,-1
je .notfound
.found:    

compared to ours:
Code:
stdcall str.cmp,[str1],[str2]
jc .error
jz .notfound
found:    
Post 29 Nov 2005, 18:28
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
new version there, fixed global data definiton bug, some more of strlib rewriten, some more fixes.
Post 29 Nov 2005, 19:35
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.