Last Updated: January 4, 2007

Quote:

Last Updated: January 4, 2007

Wow, Santa must've brought you a time machine!

;eax = size of block to allocate
        add eax,_memory_chunk_size      ; Usermemory is chunk.size-chunk_size
        add eax,PAGE_SIZE-1
        and eax,PAGE_MASK
    

jeff: are you also involved in libasm?

I was looking at it's heap management and discovered this:

Code:

;eax = size of block to allocate
        add eax,_memory_chunk_size      ; Usermemory is chunk.size-chunk_size
        add eax,PAGE_SIZE-1
        and eax,PAGE_MASK
    

do i understand it right? smallest allocable block is 4KB (PAGE_SIZE)?

That seems pretty wasty to me...

oh, maybe i mixed up the libraries. The library used in this project is AsmLib? Sorry then.

Yes, AsmLib heap management looks nice. As I see it, dword boundary alignment of block size, 12 byte overhead per block, heap corruption checking.

My heap manager in FASMLIB will align size of block to higher compile-time value, default 64bytes. This will make small increases slightly faster and hopefully reduce fragmentation of heap.

My block header will have 16 or 20 bytes, with heap corruption checking roughly equvilent to yours. I will just have signature at beggining of each block, which is pretty probable to be overwritten on some overflow.

However, AsmLib seem to support only Alloc and Free. How about ReAlloc, GetSize etc?\

Yes, AsmLib does not have REAlloc or Get Size. The GetSize
function would be easy to code, but I'm not sure about ReAlloc.
Can't think of any use for ReAlloc or what it do?

Humm, since each allocated block has its record keeping
preceeding the memory, anyone can check size by using
the allocated memory address. This is a quick GetSize function.


by the way, with these two pops out problem with saving only aligned size. GetSize should return size that was passed to Alloc, not aligned (real) size of block. Also Realloc should only preserve data of size passed to alloc, not aligned size.

I'm not sure what you mean? I think AsmLIb only deals with
real size (to nearest dword boundry). The caller is expected
to use the address as memory block identifier.

Is there some console input support in AsmLib? I couldn't find one. Something like scanf() in libc.

There are several keyboard input functions. See the heading
"key-mouse" in AsmLib index. None of the AsmLib functions
try to duplicate clib funcitons, and do not work like scanf or
printf. They do input string, keys, bytes, etc.


thanks for reply, looking forward to discussions.

Is FASLIB following the structure of a "c" stdlib format?

Where does one find the latest version of FASMLIB?

Also, I think it is great that you are working on a Linux library.

If anything of value is in AsmLib, use it for FASMLIB. AsmLib is a work in process and doesn't try to be pretty or bullet proofl, so
use the code with caution. On the other hand, it is used to create
many applications for AsmIDE and is functional.

FASMLIB is multiplatform library for 32bit x86 assembly language. It has two main purposes.

First is to get assembly programmers rid of rewriting basic routines every time. FASMLIB provides basic commonly-used routines. They are well tested, easy to use, and tend to prevent bugs in code.

Second is to allow assembly programmers have single source working for multiple operation systems. FASMLIB wraps most common routines of supported OSes, with common interface for all. Thus all your code which uses FASMLIB can run under any supported platform. Of course, this multiplatform support is limited to x86 32bit processor only. Currently win32 and linux platforms are supported.

FASMLIB is designed to allow people to use it easily with only pure assembly, without need for macros. But FASMLIB contains couple of optional high-level macros that can make it's usage even easier.

FASMLIB is NOT designed to be fast. Simplicity of usage, bugproofnes, powerfulness and maintability are more important.

FASMLIB is designed to be both simple to use and powerful. This is often solved by having two versions of procedures, one simple for common use, and one powerful

Altough name may suggest FASMLIB is only for use with FASM (Flat Assembler), this is not true. FASMLIB currently has support for FASM, MASM and NASM/YASM. Support for more assemblers can be added on demand. This name is remnaint from time when it was FASM-only library. Now I don't know about any better name. I'd take "libasm", as equvalent to "libc" but it's already taken by alive project

looked at FASMLIB memory manager. It is using the kernel mmap function, whick allocates 4k blocks (I think). That appears to be the method used by most memory managers.

AsmLib uses the kernel "ext" function which extends the end of programs. There are a few programs that use this method. I suspect the mmap is a better approach, but I find using "ext" easy and very memory efficient.

As for scanf. I've had a lot of trouble with input from stdin.

One has toworry about character blocking (avoiding splitting multi byte keys) and pipes and handling single escape characters. The "c" libraries often have trouble with single escape characters and Linux tends to avoid them. Using repeat keys (such as holding down the arrow keys) does not work well in some xterminals and often things get worse if you nest terminals on a slow cpu. A few days ago I found a blog that claimed you can't use solitary escape keys in Linux. They had examples and assumed everyone used existing libraries. Wrong!!

Regarding "cooked mode" I ignore it. Some applications switich to raw mode and leave it, others switch to raw mode just before reading the keyboard. Very few applications use cooked mode. It would be impossible to write an editor or file viewer in cooked mode.

For a few years I tried switching to raw mode at start of applications, but that was a bad idea. Now the AsmLib functions switch to raw mode just before reading a key. This appears to be what all the other libraries do.

Does all this fit with your testing? I could be spouting nonsense and not know it