AsmIDE is written in nasm but is intended as a general assembler
framework for Linux. I've added fasm to the project setup tool
but have not tested it extensivly with fasm. The debugger will
work with fasm but it much better if debug information is available
in the executable. fasm does not provide the debug information
yet.

There is another debugger called edebugger on freshmeat that
can handle symbols. Don't know much about it.

The library can be used with fasm if the source is converted
to include files. This is easy to do.

Whoops, you are right, missed that. That was the expected release date but I released early so work could begin on a trace program. Today I fixed one link on the opinion page but the date is still Jan 7.

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

That seems pretty wasty to me...

Hi vid,
No I'm not involved with libasm, but AsmLib also has
a memory manager that will handle small allocations.
It doesn't have a very efficient garbage collection, but
works OK for most applications.

It does have some advantages:
1. fast and memory efficient
2. all recordkeeping is checksumed and if
any memory area overflows (memory leak)
an error is reported.

There is a new version of AsmLIb on the web page. IIt
is included with the AsmRef update at end of download
section. This is a snapshot of work in progress, but I
don''t know of any errors. I'll be glad t answer any
questions.

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?

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.

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

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 FASLIB?

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.

no idea what is "c stdlib format". If you mean calling standard, it's quasi-stdcall, optimized for assembly usage.

EVERY! procedure return error status in CF. If CF=1, error happened, and EAX=error code. Error codes are global per library (not always -1, -2). This allows passing error code to parent procedure just by returning. This way you can preserve info about source of error.

If CF=0, there was no error, and value is returned in EAX, ZF, OF, SF. This also allows return values in flags for conditional (signed) jumps, for example in memory block or string comparison, for sorting.

Quote:

Where does one find the latest version of FASMLIB?

I announce it on every asm forum i know
Site will be [url]fasmlib.flatassembler.net[/url], but i haven't got no real "site" there. just packed and unpacked fasmlib.

Latest version is 0.4, but 0.5 is on the way. It will have much better support for other assemblers than FASM. It will support FASM, MASM, NASM and YASM, with usage docs, includes and examples.

just a note: it's not linux library. It's portable library. Right now it supports win32 and linux, but OS-dependant layer is thin, and more systems can be added easily.

Quote:

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.

Thanks. I use all libs i find in my study, but there is none i would call "bulletproof" - that is what i try to reach. Make 100% working portable library usable in all major x86-32 assemblers and systems. Some kind of "standard"

have fun

EDIT: here is excerpt from FASMLIB docs, describing what is FASMLIB:

Quote:

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

Hi Vid,
I 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 ReAlloc, I think the name should be "memory_extend" or something like that. That helps un non-"c" programmers remember what it does <grin>. I've never liked this function, because it is error prone and messy to implement. Anyway, it fits the mmap logic better than the "ext" logic.

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!!
So... if you look at the AsmLib keyboard handlers and think them strange, they are <grin>.

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.

Yes, that was my fast & dirty solution to make it work. Right now I am working on real heap manager - that is why i got interested in other libs heap management.

Quote:

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.

I think it's called "brk", no?

Quote:

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

I can believe that

Quote:

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!!

. I didn't know about multi-byte keys. hmmmm... could you point me to more info about them, how they beheave etc? Then I could support them.

[/quote]. I didn't know about multi-byte keys. hmmmm... could you point me to more info about them, how they beheave etc? Then I could support them.[/quote]

It has been years since I've seen a discusson of keyboard handlers. This leads to some startling conclusions. It appears most/all of Linux assembler code is not aware of the probelm. If that is true then the code probably isn't being used much. Sad, but probably true.

So... here is what I have found. UNIX keypress's can create a string of bytes usually starting with the escape character. The actual string of bytes for a key may vary between Linux terminals. Normally, if the program reads stdin it gets all the bytes associated with a keypress.

Problems start when keys stack up in the buffer or the program can not
keep up with keyboard activity. A program can have other programs looking at stdin first and passing the data on. The other programs may send partial key sequences and we can't not make any assumpitons about how characters are blocked in our read buffer.

To handle all this some stdin functions decode the keys first to determine when the end of a keypress sequence is complete. I think the "c" libraries do this and that is why they have trouble with "esc" keys. When they see an escape, they don't know how many keys will follow and set a timer to wait and see. This makes it almost impossibe to hold down the ESC key for repeated ESCapes.

For this reason, UNIX tends to avoid use of the ESC key. For the last 20 years no one has found a fix that handles serial terminals and all the UNIX configurations.

I've encoutered problems with character blocking several times and played with various designs. As processors get faster the problems occurs less often, but it still lurks around.

something doesn't suit me about your description... where is cooked mode? reading from stdin blocks until user presses enter, no? This applies to code that provides cooked mode, not to code that reads from console, or?

HI Vid,
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 <grin>.

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.

libc-ish functions (scanf etc) do work in cooked mode though. and that is what i consider console input. something with functionality similar to scanf.

Quote:

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.

All? AFAIK, in libc, scanf() blocks until you type entire line (cooked mode). Of course this is not usable for text editor or something, but is perfectly fine for some command line tool.

Quote:

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

my testing on linux is very poor. I'm just a linux newbie, so i rather hear to those more experienced.

just wondering: how do you switch between raw and cooked modes? ioctl?

Hi Vid
Regarding scanf() in cooked mode..
Yes, a command line tool could use cooked mode and enter the ascii string or character at the current cursor position. This was much too restrictive for me. I would rather enter the string anywhere on the screen and use a window. Also I want to control the size of buffer for string to prevent huge strings from being entered using a pipe. For these reasons AsmLib uses a get_string function in raw mode. Get_string can mimic cooked mode and more.

Regarding switching between raw and cooked mode.
I think there are some kernel functions to set terminal flags and possibly one for raw/cooked. I don't remember, because my preference is to read a block of all terminal flags and then set bits. After everything is setup write the block back. This is faster and eliminates the use of many small functions to set bits. The "c" libraries have both methods.

The terminal block is call "termios" and is a bit messy. If you have installed AsmIDE then run "asmref" and look under terminal information. The termios block is described there. The termios block has a long history and support serial terminals that origionally dominated computting.

Reading and writting the terminal block is tricky because we want to restore anything that was changed before our program exits. Failing to do this can screw up other programs. If you look at AsmLib source, there are many functions to read and write termios.

Try the terminal directory files: raw_set1 and raw_unset1
These two functions can be used to read termios, save a copy, set the raw bit, then write it back. When done, the
raw_unset1 function will restore the origional termios.

The UNIX terminal is very complex and has keyboard descriptive files plus other stuff. I prefer to ignore most of this and try to simplify how it appears to the user. The "c" libs try to handle everything and this inflates their size and slows down programs. If you strace the startup for most "c" programs the initialization code goes on forever. This is a choice that all libraries have to make. Will the library work with UNIX (posix) interface or will it use another face. Most try to mimic the "c" libraries and look like UNIX (posix) functions. AsmLIb tries to look somewhat like DOS libraries.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum