flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Examples and Tutorials > BASELIB: General purpose libs for beginners

Goto page Previous  1, 2, 3, 4, 5, 6
Author
Thread Post new topic Reply to topic
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
I updated the library (revision 1.1.18 ).

+ Minor corrections to Linux's version of "delay" routine (32 and 64-bit)

+ I am suspending all release of DLLs, SO and .O until further notice.

+ Now core files and stack32 files are combined under "core.zip" downloadable at the first post. These are the main source for the library.

As this is the 100th post, I hope no more bugs after this xD
Post 23 Mar 2016, 14:36
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14604
Location: Planet Dirt

fasmnewbie wrote:
I hope no more bugs after this

There are always more bugs to fix. Razz
Post 23 Mar 2016, 14:39
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395

revolution wrote:

fasmnewbie wrote:
I hope no more bugs after this

There are always more bugs to fix. Razz

And that's the price I have to pay to maintain just a simple library. I can't imagine Tomasz and you maintaining even more difficult things.
Post 23 Mar 2016, 15:13
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
I added the MZ version library so now you have 2 library (flat COM and segmented MZ) for 16-bit. They've been included in the first post's attachment (revision 1.1.19).

Note:

1. MZ routines support only single segment for data. That means all your data should reside inside the same segment designated for data. If you are not using any of the routine, you can use as many segments for data as you want.

2. These routines both (libcom.asm and libmz.asm) use BIOS services for default I/O. If you want to use int 21h instead, you can find the equivalent routines that use int 21h disabled at the end of the source. Replace or disable the BIOS-based routines and use / enable these instead.

3. Not fully tested. hihi xD
Post 28 Mar 2016, 00:38
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
Since the server speed is back to normal, I re-uploaded the .o, .so and DLL version of the library. If in doubt, just use the source version at post #1. But once you got annoyed by the source following u everywhere xD, you can switch to their object counterparts. I am done here and enjoy learning FASM.
Post 30 Mar 2016, 06:02
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
Fixed fatal bugs to mem_alloc (linux32 versions).

At the same time, I also added file handling routines to all 32-bit sources that were missing in previous releases. Also added "mem_load" to all 32-bit sources. So now both 64-bit and 32-bit sources are almost even in terms of total routines.

A little improvement here and there. I trimmed the doc size to help reduce site load.

I hope no more bugs after this because that would tempt me to add more routines... and eventually lead to potential new bugs and this thing can go on forever xD
Post 07 Apr 2016, 15:19
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14604
Location: Planet Dirt

fasmnewbie wrote:
I hope no more bugs ...

There are always more bugs to fix. Razz

fasmnewbie wrote:
... after this because that would tempt me to add more routines... and eventually lead to potential new bugs and this thing can go on forever

Software is never finished. Razz
Post 07 Apr 2016, 15:56
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
Added AVX support via prnymm, dumpymm and clearymm to all 320bit and 64-bit libraries. cpuid is done at the beginning of each routines to check whether you have AVX on your system.

If there's no fatal bug then take this as the final additions and edit.
Post 15 Apr 2016, 13:57
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
Just updated the libs.
Post 07 Aug 2016, 23:31
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
Updated the lib with these changes;

[+] rand - get one unsigned random int of range 0 to N
[+] randq- Generate unique random integers (unsigned) of range 0 to N-1
and save to an array
[-] rndigit - deleted
[+] int2str
[+] file_copy
Post 17 Sep 2016, 18:45
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
Just uploaded new updates. Refer to first post. Future updates / uploads maybe hosted on Google+ page. Or you can download directly from BASELIB folder
Post 02 Dec 2016, 16:47
View user's profile Send private message Visit poster's website Reply with quote
filox



Joined: 13 Feb 2013
Posts: 10
Small improvement
Hi fasmnebie,
very cool and needed lib; only a little improvement over your examples:

using native fasm object linking, you could specify also local libs to be linked to your binary files; these libs could also be in any directory, example:

- your file core_5.asm

needed 'base3.so.1.0' --> needed './base3.so.1.0'

in this way you don't need to put your libs in folders like /lib/i386-linux-gnu

Am i wrong?


Very Happy
Post 10 Mar 2017, 09:33
View user's profile Send private message Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
Hi filox. It's a useful suggestion. Users of this lib should take note.

There is a catch though. If you took it out of the system folder and place it under a user folder, the feedback from RIP is off by one or two bytes (I can't remember which). It's not wrong for users who don't really mind about the value of RIP but it does matter in 64-bit setting where code / segment should be aligned to their natural boundary. You can verify that by calling dumpreg for both versions.


Code:
segment readable executable
main:
        call [dumpreg

;Pay attention to RIP for both versions.

Anyway, appreciate your suggestion. I am always open to suggestions.
Post 11 Mar 2017, 15:39
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
BASELIB Revision 1.1.13

core.zip (source)
binary.zip (binaries)

What's New (March 27, 2017)

[1] Name changes due to conflicts with other libraries / APIs

. log10 to lg10
. pow to fpow
. rand to randm
. exit to exitx


[2] Fatal bug fixes

. prnfltr - faulty display when fraction parts have leading zeros
. prndblr - same as above
. prndble - same as above
. dbl2str - same as above
. flt2str - same as above

These pose similar effects to prnxmm, prnmmx, prnymm, dumpmmx, dumpymm, dumpxmm


[3] Parameter changes

. dumpreg no longer takes arguments for different display options. See below


[4] New

. Re-introduces dumpregd (display register dump as signed integers)
. Re-introduces dumpregdu (display register dump as unsigned integers)
. MASM 64-bit source version
. Complete set of binaries for both Win and Linux. All were compiled with FASM

Thanks to those who reported the bugs. Download the latest from the first post attachments.
Post 27 Mar 2017, 14:04
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
I'm still waiting for the delivery of my AVX512-powered PC. Lets see what more I can add to the routines (like prnzmm, dumpzmm).
Post 27 Mar 2017, 14:08
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
I am a bit worried that users of BASELIB may not get enough information on data alignment when dealing with AVX and SSE registers. This is so because I haven't put enough emphasis on that with object examples (for access to binaries);

For object format such as COFF and .O (linux), the most convenient way to align your data according to SSE (align 16) or AVX (align 32) is via section directive. Going naked flat may not help.

For COFF / MS64 COFF, you need to put your data in a section with 16 byte alignment granularity for SSE and 32-byte for AVX.


Code:
section '.data' data readable writeable align 16 (for SSE)
section '.data' data readable writeable align 32 (for AVX)


This will enable you to use "align x" larger than 4 anywhere in the data section. For example, once you set the alignment to 32 (granularity), you're now allowed to use align 16, align 8 in addition to align 32 to each of your variables. Else, COFF format supports only align 4, which is not practical for SSE and AVX.

Similarly for Linux .o format

Code:
section '.data' writeable align 16 (for SSE)
section '.data' writeable align 32 (for AVX)


You probably need to put your code in a matching section as well.

A full example, using base6.o and "ld" as the linker (Linux);


Code:
;compile: fasm this.asm 
;link: ld this.o base6.o -o this 
;run: ./this 
format ELF64 
public _start 

extrn dumpymm 
extrn dumpxmm 
extrn exitx 

section '.data' writeable align 32 
mydata  dq 13.21,21.78,11.98,56.16 
s       db 'hello',0   ;this punk breaks alignment 
align 32 
mydata2 dq 13.21,21.78,11.98,56.16 
aPunk   db 'C' 
align 16 
mydata3 dq 13.21,21.78 

section '.code' executable align 8 
_start
     
    vmovdqa ymm3,qqword[mydata2
    mov     rax,1                   ;view as packed doubles 
    call    dumpymm 
    movdqa  xmm0,dqword[mydata3
    mov     rax,9                   ;view as packed doubles
    call    dumpxmm 
    call    exitx



With this possible output


Code:
 YMM00.0|0.0|0.0|0.0
 YMM10.0|0.0|0.0|0.0
 YMM20.0|0.0|0.0|0.0
 YMM356.16|11.98|21.78|13.21
 YMM40.0|0.0|0.0|0.0
 YMM50.0|0.0|0.0|0.0
 YMM60.0|0.0|0.0|0.0
 YMM70.0|0.0|0.0|0.0
 YMM80.0|0.0|0.0|0.0
 YMM90.0|0.0|0.0|0.0
YMM100.0|0.0|0.0|0.0
YMM110.0|0.0|0.0|0.0
YMM120.0|0.0|0.0|0.0
YMM130.0|0.0|0.0|0.0
YMM140.0|0.0|0.0|0.0
YMM150.0|0.0|0.0|0.0
XMM0 : 21.78|13.21
XMM1 : 0.0|0.0
XMM2 : 0.0|0.0
XMM3 : 21.78|13.21
XMM4 : 0.0|0.0
XMM5 : 0.0|0.0
XMM6 : 0.0|0.0
XMM7 : 0.0|0.0
XMM8 : 0.0|0.0
XMM9 : 0.0|0.0
XMM100.0|0.0
XMM110.0|0.0
XMM120.0|0.0
XMM130.0|0.0
XMM140.0|0.0
XMM150.0|0.0



Hope this helps
Post 15 Apr 2017, 06:15
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 395
For executables, you have no such restrictions as mentioned above. You can use multiple alignments against variables, even without proper sections. But the good practice is always to put your data / code in the proper sections / segments.

Example (windows PE64 console)

Code:
section '.data' data readable writeable
align 8
data 1
align 32
data 2
align 16
data 3



Another example for Linux ELF64 executable

Code:
segment readable writeable
align 8
data 1
align 32
data 2
align 16
data 3



Happy coding.
Post 15 Apr 2017, 06:42
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

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

< 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.