flat assembler
Message board for the users of flat assembler.

Index > Projects and Ideas > AFS

Author
Thread Post new topic Reply to topic
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
I'm starting a project codenamed, "Assembly from Scratch." The idea will be to teach assembly (fasm syntax) to people as their first programming language. I think this'll be something that'll suffice for something fasm is missing: a way for newcomers to join in on all the fun.

I was thinking at first to make something with an OS kernel because it would be system independent and wouldn't require going into any specific calling conventions, which would make the obligatorily painful hello world a little less painful. However, that would require the user to make some special setups with bochs or something. I also want to avoid having to explain something as relatively complex as printf. I also wanted to avoid incorporating alot of extra code that the beginner might stumble upon by accident and being easily scared away (therefore FASMLIB might be a bad idea). Any solutions that are reasonable for a complete beginner would be wonderful. I'm afraid I may not be able to avoid calling conventions (I'm still not entirely sure i understand the 32bit ccall myself [something about ebp and how it knows how many things to pop off]), but if i could find something that's understood by both windows, linux, and mac users (we'll have to make any include files portable to mac when a mac version is ready, so i'll need testers for that), it'd be absolutely perfect.

Anyway, I'm starting off with programmer ethics going to hello world and beyond, and I was wondering if anyone had any ideas about what all topics to talk about and if they could come up with some example situations that favor particular topics. I plan to avoid covering every single instruction, however I do plan to include lots of practical examples of how things are done.
Post 03 Dec 2009, 10:34
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
a sort of debugger, based on source code, that will explain step by step the code.

the code can be simulated (animation). and then explain what is doing the single instruction.

can do the same with funcitons like printf, IO, int9

the main problem with asm is to explain the memory mapping, access to address, address computation, result of xor eax,eax, etc

each step of code will be explained by a little text:
example:

Code:

mov eax,[eax*4+4]
-> eax*4 in temp
-> eax+4 in temp
-> temp as a pointer
->[temp] in eax
show as eax have the value that was at [eax*4+4]
    


the Q is how to code this program?
Post 03 Dec 2009, 13:20
View user's profile Send private message Visit poster's website Reply with quote
ManOfSteel



Joined: 02 Feb 2005
Posts: 1155
ManOfSteel
From the title I thought it was going to be about a new filesystem project. Smile


To add to edfed's example, maybe you could make something like a very simple OllyDbg (HelloWorld! example), but with some more details and more user-friendly texts/descriptions inside round or rectangular callouts like in comics, that appear gradually as you trace through the code.
Post 03 Dec 2009, 13:49
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
yep
for example:
'inc eax' instruction

Code:
scenario0:
.0:
show the ram, 'cs:ip' and an arrow to the ram location
.1:
show the content of the location, a rectangle, and hex value '40h'
or a binary value for crazy explanation
.2:
arrow to source code line,text of code= 'inc eax'
.3:
arrow to the 'ALU', one to 'A', one to 'function select'
.4:
text value '1' in 'A'
text 'inc' in function select
.5:
highlight 'eax'
.6:
arrow to 'reg eax'
.7:
show eax 'value'
.8:
arrow to ALU, 'B'
.9:
execution in 'alu'
.10:
ALU output in 'C'
.11:
arrow to 'reg eax'
C to REG eax
    



11 steps, and a lot of basic events, inculding transparent events, like hide a signal, a line or something.
Post 03 Dec 2009, 14:08
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
a sort of debugger, based on source code, that will explain step by step the code.


Not sure exactly what you mean? I was thinking of doing all the lessons as source code so that the results could be explained step by step until the result is predicted, then the reader could do an assemble and run and find that the result is indeed as predicted, then the reader could change the code themselves and try to predict the result, and then test their conclusion.

Quote:
the code can be simulated (animation). and then explain what is doing the single instruction.


Well, unless someone here is actually willing to do all that drawing, it might be a bit extreeme. Flowcharts and other graphical media would be a bit excessive for some things. I'm sure i could explain these things sufficiently in words. I'm mostly worried about what topics to cover aside from the usual topics covered with HLLs (conditionals, variables, loops, etc) and computer architecture. As for additional topics, so far i've come up with input sanitation.

Quote:
the main problem with asm is to explain the memory mapping, access to address, address computation, result of xor eax,eax, etc


Well, I figure to explain things in a way that things like memory mapping are explained when the topics that concern them are introduced (memory mapping is especially practical of a topic when explaining where to put data, for example), and things like "xor eax, eax" are to become inherently obvious when that family of instructions is introduced. I actually plan on spending a whole couple of lessons on bitwise and bitshift instructions in general, where i might rip out a multiply by 2 and comment how a bitshift by one manages to accomplish that, so the beginner starts thinking in a way that if they don't understand something, and if it's not commented, they should be able to figure it out with execution by hand.

Quote:
the Q is how to code this program?


Well, doing things like adding and mulling within brackets, i'll explain my usual policy. Order of operations applies, and if the situation actually calls for something like that, try it, and if the assembler complains that that sort of combination doesn't work, just figure out the value of the register outside of the memory access. It's a safe policy, really, and it'll save me (and the reader) the trouble of having to remember what all instructions I can and can't do things like that with.

Quote:
From the title I thought it was going to be about a new filesystem project. Smile


One read of the ISO file format and you'll never want to do.

Quote:
To add to edfed's example, maybe you could make something like a very simple OllyDbg (HelloWorld! example), but with some more details and more user-friendly texts/descriptions inside round or rectangular callouts like in comics, that appear gradually as you trace through the code.


Pretty much what I'm doing, just with comments instead of pretty images.

edfed wrote:
yep
for example:
'inc eax' instruction

Code:
scenario0:
.0:
show the ram, 'cs:ip' and an arrow to the ram location
.1:
show the content of the location, a rectangle, and hex value '40h'
or a binary value for crazy explanation
.2:
arrow to source code line,text of code= 'inc eax'
.3:
arrow to the 'ALU', one to 'A', one to 'function select'
.4:
text value '1' in 'A'
text 'inc' in function select
.5:
highlight 'eax'
.6:
arrow to 'reg eax'
.7:
show eax 'value'
.8:
arrow to ALU, 'B'
.9:
execution in 'alu'
.10:
ALU output in 'C'
.11:
arrow to 'reg eax'
C to REG eax
    



11 steps, and a lot of basic events, inculding transparent events, like hide a signal, a line or something.


I was even scared when trying to read that. Laughing

Anyway, that would be doing what I'm trying to avoid, describing every single instruction. This would be rather pointless and make for a very boring read. I'll explain that the add instruction (by the time i mention it, i'll have already covered memory mapping and the mov instruction, and naturally memory oprands) takes 2 oprands, where it add both oprands together and stores the result in the destination oprand. Then to describe inc, i will say that it's a smaller opcode that essentually does the same as "add oprand, 1."
Post 03 Dec 2009, 14:41
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
Great project Smile, i am always being asked for a good tut on fasm, but the biggest thing that is missing is a 32bit mode asm programming tut (not window as we have them).
99% of the asm tuts are based on 16bit realmode, the best thing to do is to take a good asm dos tut and convert it to 32bit mode with the same examples etc, so newbees can learn and compare the two.
The best one i found, was Adams asm tut
http://www.programmersheaven.com/download/15526/download.aspx

I also think your tut should be based around a fasm hobby OS's, maybe MenuetOS/KolibriOS
As i am making a MenuetOS/KolibriOS functiom wrap, so the same code will work on DexOS too.
Post 03 Dec 2009, 17:52
View user's profile Send private message Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
very nice idea Very Happy
I started my vCalculator some months ago. The concept is something like edfed says in his example/explanation, but related only to calculations that will be showed regarding flags and partial results.
For example
setting a variable in eax and ecx

1) xor eax,eax ;<--- show flags / result of eax
2) and eax,ecx ;<--- show flags /results for eax /ecx
...
and so on

Also, it is possible to study flags and partial results at each single step , for the common logical/arithm operations. In this way it may become more accessible task that of start coding a simple xor engine, or a decompression module, for example.

At the moment i have no time to dedicate myself to this nice idea.
I am releasing fasmlab (with code hihlight/block commenting/verticals selection etc..) in few days, it is to say, before Christmas
fasmlab before Christmas Laughing ....
but pehraps the new year will bring something really cool from this
thread,
or i hope so...

Regards,
hopcode
Post 03 Dec 2009, 22:52
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
Great project Smile, i am always being asked for a good tut on fasm, but the biggest thing that is missing is a 32bit mode asm programming tut (not window as we have them).


I figure the best way for people to learn is to learn as i have learned. Even into the days of 128 bit, 32bit mode stuff will still be a good starting place. 16bit mode is complicatedwith trying to explain the whole memory setup. I figure, one can learn 64bit stuff just by reading the 64bit section of the fasm manual. My goal is to get a small tutorial, that gets someone basically far enough that they don't have to fear the intel docs and they have at least a basic idea on how to code and why some people do some things like "xor rax, rax" or jump tables over a massive chain of compare statements, etc. People simply can't learn assembly in general, or assembly from scratch, only from the fasm examples. This is to get people ready for the fasm examples.

Quote:
99% of the asm tuts are based on 16bit realmode, the best thing to do is to take a good asm dos tut and convert it to 32bit mode with the same examples etc, so newbees can learn and compare the two.


Well, i might do that and i might not. I want to avoid possibly scaring people, and doing DOS stuff will. I might just add an extra lesson for 16bit code.

Quote:
I also think your tut should be based around a fasm hobby OS's, maybe MenuetOS/KolibriOS
As i am making a MenuetOS/KolibriOS functiom wrap, so the same code will work on DexOS too.


Well, i'm trying to be practical with my expectation of my audience. You might be able to convince them to run another OS, but once again, that'll require them to figure out how to burn it and such. This wouldn't be a problem for people who learned other languages first, because they wouldn't be afraid of "blowing up" their computer. If i can get some kind of cross platform wrapper started to work with windows, linux, and potentially mac, i surely won't shy away from one for a hobby OS either. All i'm looking for in my basic setup is a "print string" and "get string" macro.

hopcode wrote:
very nice idea Very Happy
I started my vCalculator some months ago. The concept is something like edfed says in his example/explanation, but related only to calculations that will be showed regarding flags and partial results.
For example
setting a variable in eax and ecx

1) xor eax,eax ;<--- show flags / result of eax
2) and eax,ecx ;<--- show flags /results for eax /ecx
...
and so on

Also, it is possible to study flags and partial results at each single step , for the common logical/arithm operations. In this way it may become more accessible task that of start coding a simple xor engine, or a decompression module, for example.

At the moment i have no time to dedicate myself to this nice idea.
I am releasing fasmlab (with code hihlight/block commenting/verticals selection etc..) in few days, it is to say, before Christmas
fasmlab before Christmas Laughing ....
but pehraps the new year will bring something really cool from this
thread,
or i hope so...

Regards,
hopcode


I'll do something like that. Basically, to save myself all the writing and them all the reading, i'll explain flags when i go into conditional jumps. I'll tell them to stay on the lookout for such things, and i'll give them a basic program to help them check if a particular instruction changes that flag or not, etc.

After the first couple lessons, y'all'll know exactly where i'm going with this. At this point, i think i'm gonna make a wrapper function for printf that simply uses a "%s" format string. But, i'll get to that after i finish this ethics lesson and post it here for corrections and comments.

EDIT: Here is my first draft. I'll be posting the first couple lessons regularly while creating them so that i can get an extra pair of eyes making sure i don't make things too scary and to make sure i'm thorough. I'm sure this first draft will have lots of comments and corrections, since i stopped in the middle of writing it after looking at the URL i referenced, as i thought that it would suffice for alot of things.

Quote:
The first and most important thing to learn is ethics. Most textbooks leave this until a late section, which often makes tempting situations before revealing the seriousness of having decent ethics. As a programmer, you will take on both the fames and burdens of other programmers. Just like joining a religion, if you do bad things, you make everyone else look bad. However, unlike a religion, there are only a few simple guidelines to follow (though, many would love to make more). These are mostly rules accepted by programmers to insure that only good things happen (much like the ethics followed in a scientific community), but unfortunately, not everyone follows the rules (like people in the scientific community with an agenda).

First and foremost, you can indeed impress someone by making a supervirus that can make the computer act strangely, but releasing it on the world and annoying those less informed will win you no attention (unless you get arrested) and will surely ruin the view people have of programmers. I, for one, have lots of bad experiences where people end up with a computer problem, then they blame me because I'm the only person they know personally who knows how to make computer programs. They simply assume that I must be the cause.

This leads me to the second rule, you can't be lazy. Lazy people make buggy programs which tend to fall apart. I'm sure you would never use microsoft word if it were to receive a fatal error every 2 or 3 pages of typing and you couldn't recover your documents. You need to make things that are reasonably "robust." "Robust" is often a keyword used by many programmers and employers who wish to describe the quality of someone's code ("code" is what programmers write which turns into a usable computer program). If it's robust, it's never bad unless you're trying to show an example of a bad program or security system. Conversely, as part of this rule, sometimes robustness needs (or can reasonably be) sacrificed for speed, which is often important, because you don't want to wait 10 minutes for the computer to add two numbers together simply because you felt that the program should continually check to make sure the user typed a number. If robustness is sacrificed (usually only best when coding for another programmer), it's expected that you tell the person using your code what all could go wrong and what would cause that to go wrong.

Now, like before, the third rule was led into by the last statement. You must communicate with people about using your code, and let them know of the dangers of your code. This is called "documentation." This term is used alot, and not just inside programmer circles. Nothing except a slow and buggy program angers people more than a program that they paid for but don't know how to use. It's bad to underdocument, but don't overdocument either because then people will be too bored with it to figure out how to use it. Ever had to figure out how to use a fancy coffee pot or your first cellphone? Surely you thought it was easy, you ended up making a mess of things, then you looked in the trash for the instruction booklet. Sometimes, if the code is small enough, and it's only for programmers, keeping it "readable" is sufficient documentation. In the next lesson, you'll be introduced to some code, and something called a "comment" will prove useful for documenting code that is difficult to read. This rule is also very useful to you, because you may easily forget what something in you code was intended to do.

These rules essentially fall under only section 1.2 of the ACM's "Code of Ethics." I recommend everyone get to understand the responsibility that comes with programming, looking up many codes of ethics and so forth to get a real feel for what's expected of you. My most recommended reading is the following url, which is often copied into many, many textbooks for programmers:

http://www.acm.org/about/code-of-ethics
Post 03 Dec 2009, 23:53
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
I think for it to really stick and keep their attention
it has to have a certain WOW factor in its display.
Now a graphical tutorial would get their attention and keep it.
I myself had thought an OpenGL::Win32 tutorial would be popular...
But i guess there was not so much interest in it these days...
I also thing an OS for beginners tutorial would be a good one.
And i do like the idea of building a debugger to follow the code Smile
Post 04 Dec 2009, 04:09
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Well, i figured to do what most languages today do. Regular console mode stuff with only a few functions, but mostly using some sort of routine for printing and getting strings and numbers. Going into GUI and all of that would probably result in so much work and time going into the project that it'll be obsolete before it's finished (because people stopped using that GUI system for some reason). Plus then, using something like making our own visual basic for the purpose of learning would probably require a bunch of extra DLLs and SOs and stuff and just add to the process of getting the user ready for coding. As it stands right now, i'm writing it so that the tutorial can be copied into the fasm directory and be worked with from there, modifying a wrapper file to change which lesson the assembler tries to compile.

Certainly, though, if anyone is willing to do the work, i won't stop anyone from forking it. the wrapper code itself is based on code Tomasz wrote, and i'm just adding a little extra to it. Other than that, i'm releasing it all public domain, really. You have my permission to utterly destroy whatever i come up with. Laughing I'm just looking for advice on where to go with what i have right now (despite not having anything to show for it at the time of posting this) lesson plan wise.

EDIT: First binary making lesson doesn't exist yet, but the framework testing the macro are. I tested for windows using wine, but anyone using various versions of windows (XP through 7), testing would be recommended.

EDIT2: First three lessons complete, in the process of writing lesson 03 (fourth lesson). Comments and testing still required...


Description:
Download
Filename: asmfromscratch.zip
Filesize: 11.7 KB
Downloaded: 487 Time(s)

Post 04 Dec 2009, 04:53
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 824
Location: Jakarta, Indonesia
TmX
Would this be something like PC Assembly Tutorial ?
Post 04 Dec 2009, 12:31
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Dang, someone beat me to it. Either way, I'm hoping to be as verbose, but teaching a few other things along the way and to teach in a relatively different order. You know though, that would've been really nice to have when i started learning assembly... I will say though, i'm just glancing over it and it's using words that someone might not be familiar with unless they already know a programming language, which is not what my project does.
Post 04 Dec 2009, 12:54
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
masonswanson



Joined: 17 Aug 2010
Posts: 51
masonswanson
Well i am working on A Small assembler in python, python is usually hailed as the best for teaching newbies, so with the power of python and the ease of assembly... or whatever... I have plans in the work for the assembler to create verbose documentation on the source code it compiles, or translates between dialects, that way with the addition of a command line switch you can have it output documentation for third party users of the code. i also plan on having some sort of inline documentation, so it can extract the comments from the code for inclusion in the output documentation, but it's primary purpose would be in creating a verbose description of each instruction. as far as interrupts go, i am trying to work on a parser for Ralf Brown's interrupt list
Post 23 Dec 2010, 20:59
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.