flat assembler
Message board for the users of flat assembler.
Index
> Tutorials and Examples > BASELIB: General purpose libs for beginners Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next |
Author |
|
revolution 23 Mar 2016, 14:39
fasmnewbie wrote: I hope no more bugs after this |
|||
23 Mar 2016, 14:39 |
|
fasmnewbie 23 Mar 2016, 15:13
revolution wrote:
|
|||
23 Mar 2016, 15:13 |
|
fasmnewbie 28 Mar 2016, 00:38
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 |
|||
28 Mar 2016, 00:38 |
|
fasmnewbie 30 Mar 2016, 06:02
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.
|
|||
30 Mar 2016, 06:02 |
|
fasmnewbie 07 Apr 2016, 15:19
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 |
|||
07 Apr 2016, 15:19 |
|
revolution 07 Apr 2016, 15:56
fasmnewbie wrote: I hope no more bugs ... 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 |
|||
07 Apr 2016, 15:56 |
|
fasmnewbie 15 Apr 2016, 13:57
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. |
|||
15 Apr 2016, 13:57 |
|
fasmnewbie 07 Aug 2016, 23:31
Just updated the libs.
|
|||
07 Aug 2016, 23:31 |
|
fasmnewbie 17 Sep 2016, 18:45
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 |
|||
17 Sep 2016, 18:45 |
|
fasmnewbie 02 Dec 2016, 16:47
|
|||
02 Dec 2016, 16:47 |
|
filox 10 Mar 2017, 09:33
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? |
|||
10 Mar 2017, 09:33 |
|
fasmnewbie 11 Mar 2017, 15:39
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] Anyway, appreciate your suggestion. I am always open to suggestions. |
|||
11 Mar 2017, 15:39 |
|
fasmnewbie 27 Mar 2017, 14:04
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. |
|||
27 Mar 2017, 14:04 |
|
fasmnewbie 27 Mar 2017, 14:08
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).
|
|||
27 Mar 2017, 14:08 |
|
fasmnewbie 15 Apr 2017, 06:15
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: YMM0: 0.0|0.0|0.0|0.0 YMM1: 0.0|0.0|0.0|0.0 YMM2: 0.0|0.0|0.0|0.0 YMM3: 56.16|11.98|21.78|13.21 YMM4: 0.0|0.0|0.0|0.0 YMM5: 0.0|0.0|0.0|0.0 YMM6: 0.0|0.0|0.0|0.0 YMM7: 0.0|0.0|0.0|0.0 YMM8: 0.0|0.0|0.0|0.0 YMM9: 0.0|0.0|0.0|0.0 YMM10: 0.0|0.0|0.0|0.0 YMM11: 0.0|0.0|0.0|0.0 YMM12: 0.0|0.0|0.0|0.0 YMM13: 0.0|0.0|0.0|0.0 YMM14: 0.0|0.0|0.0|0.0 YMM15: 0.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 XMM10: 0.0|0.0 XMM11: 0.0|0.0 XMM12: 0.0|0.0 XMM13: 0.0|0.0 XMM14: 0.0|0.0 XMM15: 0.0|0.0 Hope this helps |
|||
15 Apr 2017, 06:15 |
|
fasmnewbie 15 Apr 2017, 06:42
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. |
|||
15 Apr 2017, 06:42 |
|
Inagawa 02 Jul 2017, 19:17
Awesome, the way you approached it makes it really simple to import and use. Thanks!
|
|||
02 Jul 2017, 19:17 |
|
fasmnewbie 05 Jul 2017, 05:30
Inagawa wrote: Awesome, the way you approached it makes it really simple to import and use. Thanks! |
|||
05 Jul 2017, 05:30 |
|
fasmnewbie 05 Jul 2017, 05:44
Sometimes you just want to see the encoding of an instruction
1. in a safe conditions without breaking anything 2. that is not supported by your current CPU 3. too exotic / restrictive to code normally in protected mode BASELIB 's opcode routine may help you to do just that. What this routine does is to display an opcode of ONE instruction between 2 labels, and at the same time will report to you visually the size of such instruction. This routine also show you how different assemblers may differ in generating the opcode if called from other assemblers. On certain conditions though: 1) if you're testing prohibitive system instructions, it is advisable to test them out of the execution path. This way, you can safely view the generated opcode in a much controlled environment. 2) Your instruction must be valid as per manual If it says error, it is highly likely that 1) the assembler doesn't support / encode it just yet 2) the assembler generated wrong encoding Below is a small list of "exotic" instructions that you can investigate by using "opcode" routine. TBH, I don't know how far it can go with ring-1 or 2 system instructions but you give it a try and see how it goes from there. Code: format PE console include 'win32axp.inc' entry main ;Test/Enable one instruction at a time ;This must be out of execution path ;The generated opcodes is up to your assembler a: ;skinit eax ;vmmcall ;invlpg [x] ;stgi ;clflush [y] ;icebp ;sha1msg1 xmm1,xmm2 ;rsm ;hlt ;mov cr3,eax ;mwait ;monitor b: section '.data' data readable writeable x rb 40 y rb 8 section '.code' code readable executable main: mov eax,a mov ebx,b call opcode call halt call exitx Have a safe journey down there |
|||
05 Jul 2017, 05:44 |
|
Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.