Index
> Tutorials and Examples > BASELIB: General purpose libs for beginnersGoto page Previous 1, 2, 3, 4, 5, 6, 7 Next |
| Author |
|
|
fasmnewbie 28 Oct 2015, 16:25
I added "memview" and "encoder" as two core routines.
1) memview - display memory content from a defined label 2) encoder - display encoding for instructions between two labels These latest additions should help beginners to understand more about memory (usage, addresses) and how their instructions are encoded (instruction size, placement and encoding). I intend to turn these library to DLL and SO form instead so that it can run cross assemblers / compilers and can promote better information hiding. But I am having second thoughts about it because it will no longer be open source. On the other hand, exposing codes that should be hidden may not be appropriate in formal education environment. I don't know. Only time will tell. But for sure I am not releasing both the source and binary format. See you all again next year. Year-end auditing work is stacking up mountain high. LOL |
|||
28 Oct 2015, 16:25 |
|
|
typedef 07 Nov 2015, 17:35
Debuggers are not counter productive. The word even describes what they do. They help you identify bugs. If you debug your code thoroughly you won't have to go back and forth trying to figure out why nothing is working.
|
|||
|
07 Nov 2015, 17:35 |
|
|
fasmnewbie 08 Nov 2015, 07:28
typedef wrote: Debuggers are not counter productive. The word even describes what they do. They help you identify bugs. If you debug your code thoroughly you won't have to go back and forth trying to figure out why nothing is working. That's what's this library is all about. Beginners can code & debug at the same time so that they don't waste their time going back and forth the debugger. That is to say they can prevent bug from occurring in the first place. I don't know about you but I'm not relying on C/C++ programmers to write a debugger so that I can check what's wrong with my low-level assembly code. See the irony here? Assembly programmer will have to rely on C programmers / programs to see what's going down with their own assembly code???? LOL |
|||
|
08 Nov 2015, 07:28 |
|
|
randall 10 Nov 2015, 11:34
fasmnewbie wrote:
But you are relying on a Linux kernel which is written by C programmers  |
|||
|
10 Nov 2015, 11:34 |
|
|
fasmnewbie 10 Nov 2015, 13:14
randall I am referring to people's obsession with debugger, not with kernel. Even FASM rely in some way on windows library/headers to make it work on Windows. You are missing the point. Besides, syscall is the lowest I can go for this little 'app' without breaking anything on the user's side or on my side. Btw, I do have the 16-bit version of this library using the BIOS interrupt services. No C.
I have nothing against debuggers or C programs. My only issue is that assembly programmers are pushing the idea of 'must-have debugger or you die'. That really is burdensome to assembly beginners when in reality the use of debugger can be completely avoided by using library like this, by assembly programmers, for assembly beginners. More time can be saved because beginners can code and debug at the same time. But I have to admit that debugger is inevitable when it comes to advance things like windows programming. But this library involves no such headers. Just simple command-line assembly library. A debugger may be easy for an individual PCs/users, but for large multi-platform learning institutions with hundreds of non-standard PCs, a debugger will be too luxurious to implement. So the safest, easiest and cheapest alternative is a library like this one  |
|||
|
10 Nov 2015, 13:14 |
|
|
TmX 10 Nov 2015, 16:23
fasmnewbie wrote:
In reality, sometimes programmers are just lazy to fire up the debugger, and use the good old 'printf' instead |
|||
|
10 Nov 2015, 16:23 |
|
|
revolution 10 Nov 2015, 17:11
People will do what they find the most comfortable at the time. Sometimes I use a debugger, sometimes I just print out debugging information. I do whatever is easiest and most prudent to fixing the problem.
I don't agree that printf is always better than debugger, or that a debugger is always better than printf. Each has its place. And learning to recognise when to use each one is a very important skill. |
|||
|
10 Nov 2015, 17:11 |
|
|
codestar 10 Nov 2015, 20:12
fasmnewbie: Good work!
I use both s/printf and debuggers - homemade disassemblers, FASM "display" and PE Browse Pro for .EXEs - whatever is the fastest, easiest and/or most convenient. After you finish a LL library in ASM, you may decide later to create a separate higher level DLL in C or FASM macros that encapsulates all of this with Windows UI and controls. Iczelion's Windows ASM Tutorials (MASM is easy to translate). |
|||
|
10 Nov 2015, 20:12 |
|
|
rbprsp 11 Nov 2015, 06:42
fasmnewbie: Really good work & my favorite thread on this board atm. Thanks for your effort!
revolution: I doing the same things for debugging + sometimes using disassembler "IDA Pro" - fastest way & fresh look to my code. |
|||
|
11 Nov 2015, 06:42 |
|
|
fasmnewbie 13 Nov 2015, 01:53
I changed the source to a new name CORE64, reflecting my intention to turn these library into SO and DLL soon.
I altered "memview" so that the Address column is placed on the right. The content is now read from left-to-right. Left=MSB and Right=LSB. For example, an attempt to probe the memory dump backward to read the ELF64 header; Code: mov rax,$ ;start reading from current location mov rbx,-78h ;read backward up to base address call memview producing this output, which in some way reflecting the same idea as Linux readelf Code: MSB LSB Address 00 00 00 00 00 00 10 00 |0000000000400070 00 00 00 00 00 00 32 C5 |0000000000400068 00 00 00 00 00 00 32 C5 |0000000000400060 00 00 00 00 00 40 00 78 |0000000000400058 00 00 00 00 00 40 00 78 |0000000000400050 00 00 00 00 00 00 00 78 |0000000000400048 00 00 00 07 00 00 00 01 |0000000000400040 00 00 00 00 00 40 00 01 |0000000000400038 00 38 00 40 00 00 00 00 |0000000000400030 00 00 00 00 00 00 00 00 |0000000000400028 00 00 00 00 00 00 00 40 |0000000000400020 00 00 00 00 00 40 00 78 |0000000000400018 00 00 00 01 00 3E 00 02 |0000000000400010 00 00 00 00 00 00 00 00 |0000000000400008 03 01 01 02 46 4C 45 7F |0000000000400000 ;ELF64 ... executable 3 I am not sure if this new arrangement will be the best, but I am more comfortable reading the content from left-to-right, from MSB to LSB. The address represents the offset of the byte nearest to it. For example address 0x400058 contains 78h, 0x400059 contains 0, 0x40005a contains 40h and so on. |
|||
|
13 Nov 2015, 01:53 |
|
|
fasmnewbie 13 Nov 2015, 02:07
As for "encoder" routine, I am not very sure how to properly implement it as I don't have good knowledge on encoding, plus there's no way we can be fully sure of what those opcodes really represent. For example 48h is either DEC or it could be a REX prefix. DON'T ASK ME. I DON'T KNOW. I just print them out for you xD
|
|||
|
13 Nov 2015, 02:07 |
|
|
fasmnewbie 13 Nov 2015, 02:10
TmX wrote: In reality, sometimes programmers are just lazy to fire up the debugger, and use the good old 'printf' instead they are both C. yucks! xD |
|||
|
13 Nov 2015, 02:10 |
|
|
revolution 13 Nov 2015, 02:12
fasmnewbie wrote: ... there's no way we can be fully sure of what those opcodes really represent. For example 48h is either DEC or it could be a REX prefix. DON'T ASK ME. I DON'T KNOW. |
|||
|
13 Nov 2015, 02:12 |
|
|
fasmnewbie 13 Nov 2015, 02:14
codestar wrote: fasmnewbie: Good work! I don't know how many years to go so I can finally catch up with you. By looking or should I say 'staring' at your codes, I probably never will. You are way too advance my friend. |
|||
|
13 Nov 2015, 02:14 |
|
|
fasmnewbie 13 Nov 2015, 02:17
revolution wrote: In 64-bit mode it is always a REX prefix. In 32-bit (and 16-bit, but who uses that?) mode it is always DEC. |
|||
|
13 Nov 2015, 02:17 |
|
|
fasmnewbie 13 Nov 2015, 02:28
rbprsp wrote: fasmnewbie: Really good work & my favorite thread on this board atm. Thanks for your effort! Well, if you are a fan, then you must be a beginner too! Advanced players don't use this my friend xD |
|||
|
13 Nov 2015, 02:28 |
|
|
revolution 13 Nov 2015, 02:31
No, REX by itself does nothing other than to modify the following instruction for 64-bitness. In 64-bit mode only the two-byte DEC instruction is available.
|
|||
|
13 Nov 2015, 02:31 |
|
|
fasmnewbie 13 Nov 2015, 02:31
@revo
ok. |
|||
|
13 Nov 2015, 02:31 |
|
|
fasmnewbie 07 Dec 2015, 09:41
Added a very basic 16-bit version. Missing many routines but should be enough for learning purposes in 16-bit environment. All-BIOS interrupts. Flat COM format (org).
Under emulators like DosBox, some floating point routines may not work properly. Happy holiday and good luck. |
|||
|
07 Dec 2015, 09:41 |
|
| Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next < Last Thread | Next Thread > |
Forum Rules:
|