flat assembler
Message board for the users of flat assembler.

Index > Main > Memory Version of FASM - first step of FASM port to FAMOS

Author
Thread Post new topic Reply to topic
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Memory Version of FASM - first step of FASM port to FAMOS

The attached file contains FASMF sources and binary, a "memory only" version of FASM for DOS, which hopefully will become the basis of my FASM port to FAMOS.

It also contains LOADSRCE, a DOS utility which will load any source file into RAM, ready to be assembled into memory by FASMF.

I thought this might be of general interest, so I posted it here rather than under "DOS".

FASMF requires DOS in Flat Real Mode, and in this version it works with a fixed and reasonably compressed memory map as follows:

400000H (4th megabyte): pre-processed/parsed source
600000H (6th megabyte): flat binary output code generated by FASMF
800000H (8th megabyte): source code loaded by LOADSRC, to be assembled
up to 800000H: labels_list created during assembly extends down from 800000H, 3 times the size of source code (?)

With this structure FASMF should be able to safely assemble source files of 5512K, and/or produce up to 512K approx. of flat binary code.

FASM itself appears to use memory fairly "liberally", spread right across the address range. e.g. the source is placed near the top of addressable memory, while the preprocessed source is written just above the 1MB range. This would not be permitted under FAMOS of course Wink
Also because of some other ways FASM uses memory I can see some potential difficulties in porting it to FAMOS, but nothing is impossible of course Smile

To use FASMF, first load your source to 0:800000H using LOADSRCE:
LOADSRCE yoursrce.asm (LOADSRCE also sets up Flat Real Mode in plain DOS)
Then just run FASMF from the DOS prompt with no parameters.

If the code is successfully generated, the word "successful" is printed, otherwise an error message will be printed which may or may not be meaningful! You can check the accuracy of the generated code at 0:600000H with your favourite debugger, and/or compare it with the same code assembled by your favourite version of FASM.

The source must be completely self-contained (no INCLUDE's, or FILE directives etc), and FASMF does NO CHECKING of this at the moment. The original code for INCLUDE's etc has NOT been disabled. Macros in the source are OK.

Sorry that the FASMF sources are a bit messy for now. I've been busy hacking... Very Happy They are from FASM version 1.48, and were assembled using the same version.

I've tested FASMF with a few of my sources and it seems to be working fine.

I hope I have properly explained what I'm trying to achieve here, and thanks in advance to anyone who takes the trouble to try it out for themselves, and gives feedback !


Description: "Memory Only" Version of FASM for DOS
Download
Filename: FASMF.ZIP
Filesize: 73.87 KB
Downloaded: 259 Time(s)


_________________
FAMOS - the first memory operating system
Post 11 Sep 2008, 21:08
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
During more testing I discovered that FASMF doesn't process the DD directive correctly - it assembles only the lower 16 bits of the doubleword Surprised . This is the only problem I have seen so far.

All other data definition directives are handled correctly, including DB, DW, DQ, DP and DT.

Right now I have no idea what I've done that would cause this ... and why it only affects doublewords, but not quadwords etc.

Maybe somebody who is more familiar with the inner workings of FASM might have an idea?

_________________
FAMOS - the first memory operating system
Post 14 Sep 2008, 04:33
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
maybe you should not code fasmf for flat rm, but pure RM.
then, there will be a limit of 600k for code and compile. but it will work everywhere.
Post 14 Sep 2008, 09:38
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
edfed wrote:
maybe you should not code fasmf for flat rm, but pure RM.
then, there will be a limit of 600k for code and compile. but it will work everywhere.

OK, maybe pure real mode will make it easier for people to test it? But I doubt it will fix the DD problem... Sad

I will post FASMR in the next few days (Real Mode version of FASMF), with the FASMF memory map divided by 16. So the memory map will be:

40000H (4th 64K segment): pre-processed/parsed source
60000H (6th 64K segment): flat binary output code generated by FASMR
80000H (8th 64K segment): source code loaded by LOADSRCR (real mode version of LOADSRCE)

The maximum source code size will be about 32K to be safe.

Not sure if it will work though. I imagine DOS would need to have at least 448K free, but it would probably be safer not to load DOS high. Just don't load too many TSR drivers etc!

_________________
FAMOS - the first memory operating system
Post 14 Sep 2008, 23:08
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Hurray, I tracked down the "DD' bug in FASMF - it was just a small typo, some original code unintentionally deleted during editing. So now FASMF is working perfectly and I can proceed with the FAMOS IDE project Cool

Because FASMF hasn't generated much interest so far, I won't bother posting the bugfix unless somebody asks for it...

I've also created FASMR which works entirely in conventional memory (and disables A20 to prove it!) but it is pretty limited e.g. maximum code size less than 64K. With some tweaking up to maybe 128K of code could be generated, but I also won't bother posting FASMR unless anybody wants it.

_________________
FAMOS - the first memory operating system
Post 18 Sep 2008, 03:07
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
neville wrote:
...I won't bother posting the bugfix unless somebody asks for it...
Great, I am looking forward to it.
neville wrote:
...I also won't bother posting FASMR unless anybody wants it.

I am not a devotee of limited memory applications, so, I will pass on asking for this version.
Thanks again for your very interesting project.

One (perhaps annoying) request, is that you elaborate a bit, explaining HOW you found the typographic error?

For years, on this forum, I sought, in vain, to argue in favor of MOV reg, zero, rather than XOR reg, reg, in part, because of my apprehension regarding the problem of finding a small typo, when someone inadvertantly typed, for example xor ecx, eax, intending to clear one (or both) registers.

Did you use a debugger? Did you use two monitors concurrently, (or two printouts) one with the original code, one with your modified version, and then scroll down? How much time was required for this process: hours, days?

Apart from learning more about how you found the typographic error, I would also profit from reading why you selected that particular version of FASM, and not one of the newer versions, though you may have elaborated this in an earlier post (sorry, if so--you know, dementia!). Finally, Neville, I am curious how you will maintain your version going forward--for example, will you gradually add those features currently disabled, or, will FASMF become an entirely distinct entity, with unique syntax requirements, and user functions? Apologies again, if you have already explained this, previously.
Post 18 Sep 2008, 09:17
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Ok Tom (deep breath Wink ), first my debugging strategy in this case:

1. isolated the faulty code module by starting with original working source and substituting mods until the bug appeared
2. discovered faulty code was only one byte shorter than working code, so easier to compare binaries than sources (lots of hacks in source)
3. used my home-grown "compare" utility with a debugger to quickly find where the code becomes continuously different (single byte differences ignored because due to memory references)
4. disassembled code and found corresponding place in source (somehow a stos dword[ ] had lost its d and become stos word[ ].

A very small typo in this case, but quite self-evident. Total time about 90 mins, maybe a little more. Strategy depends on the circumstances, sometimes use 2 PC's, but very seldom do I use printouts.

Now before I continue, would very much appreciate some feedback Smile

What is your area of interest? What do you think of the concept of a Memory OS ? Have you tried FAMOS ? If so, what have you discovered using FAMOS ? FD or CD version? Any particular problems, and what platform? etc. etc. Thanks! Smile

_________________
FAMOS - the first memory operating system
Post 18 Sep 2008, 11:00
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
Did you use a debugger?

Finally a good idea. Catching typo like "xor ecx, eax" is matter of minutes with debugger. Based on what you told me about your style of development, "mov eax, 0" with your style takes more time for coder than finding and fixing "xor ecx, eax" takes to common asm programmer.

Really, doing programming the "sciency" way is not very effective.

Quote:
Did you use two monitors concurrently, (or two printouts) one with the original code, one with your modified version, and then scroll down? How much time was required for this process: hours, days?

http://gnuwin32.sourceforge.net/packages/diffutils.htm Razz
Post 18 Sep 2008, 12:12
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
neville wrote:
...appreciate some feedback ...(a) What is your area of interest? (b) What do you think of the concept of a Memory OS? (c) Have you tried FAMOS? (d) If so, what have you discovered using FAMOS? (e) FD or CD version?
a= assembly language programming;
b= excellent,
c= not yet, awaiting your update with the bug fix,
d= n/a,
e= n/a.

vid wrote:
...Really, doing programming the "sciency" way is not very effective. ...
I appreciate your comments!
I am not persuaded, based upon this thread, or our interesting and useful conversations together, in person, that I err in this regard. However, I do agree that you and Tomasz are both very skillful, despite working exactly the contrary of the way I propose!! My experience has taught me that RAPID development, without bothering to define data structures or elucidate the algorithm invariably leads to chaos when the client ultimately decides to make a small change in the execution, and seeks guidance from someone NOT on the original programming team. The value of "scientific" programming is not found in assessing the productivity of a single individual working by, and for, himself/herself. Its attractiveness increases as the quantity of warm bodies actively participating on a project augments. It really achieves a glorious status only with the passage of time, when one suddenly discovers how easy it is to alter "old" code, if that code has been thoroughly documented, and written like a novel by Tolstoy, with the cast of characters (i.e. meaningful variable names)elaborated at the outset. It is precisely that effort, to define BEFORE coding, what it is that one intends to accomplish, and how one will succeed, that separates professional "scientific" programmers from amateur coders.

You and Tomasz succeed by "writing" the documentation in your minds, as you type code on the keyboard. Your code is sparse, Spartan, and highly inscrutable. That's not bad. It's just a style. Many people prefer your style. Some believe, erroneously in my opinion, that such a style makes it more difficult to pirate precious code. Maybe most folks given the choice, would prefer your approach. I do not. I want to see those same adherents' faces when, one day, in a decade or so, a client asks a newcomer to his employ, to fix a couple of nagging problems with the code from ten years earlier. 90% probability that the client will find it more cost effective at that point, a decade after the fact, to simply hire new programmers to start over, than to pay that same group of newcomers to try and repair/modify the original spaghetti code...
Post 18 Sep 2008, 17:24
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
Quote:
I've also created FASMR which works entirely in conventional memory (and disables A20 to prove it!) but it is pretty limited e.g. maximum code size less than 64K. With some tweaking up to maybe 128K of code could be generated, but I also won't bother posting FASMR unless anybody wants it.


super! i want it Very Happy

proof, if it exists, i can do something like real time assembly.
a little code that will write lines of text, and call fasmr as if it was an INT.

for example, int 0fah
Code:
int_0fah:
;esi curent item
.parse=0   ;pre-processed/parsed source 
.output=2  ; flat binary output code generated by FASMR 
.source=4  ; source code loaded by LOADSRCR (real mode version of LOADSRCE) 
call fasmr
iret
include 'fasmr.asm'
    


thanks!
Post 18 Sep 2008, 18:04
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
tom, your questions are welcome, and of course I will answer them, but I'm less than impressed with the quality of your feedback Wink


score sheet for tom:

a= assembly language programming; OH REALLY? >ARE YOU SURE?
b= excellent, >thanks, but TOO BRIEF!
c= not yet, awaiting your update with the bug fix, >SEE BELOW
c: you didn't understand, or you misread, the question - which was asking about FAMOS, not FASMF. Bugfixes for FASMF have nothing to do with FAMOS. FASMF is a DOS program! FAMOS is an entire OS, with many applications and stuff to try out. FASMF has some way to go before it can run under FAMOS.

d= n/a, >X
e= n/a. >X
f= .... >X

Result: FAIL

Comment: a perfunctory effort
Recommendation: try again



I stopped my post (answering your questions) last night because I was tired and it was way past my bedtime, so I thought I would just ask for some feedback in the meantime.

But, dammit, can't anybody give a guy some honest well-considered feedback on their Pet Projects around here Question
Am I right in thinking that honest well-considered feedback about our projects is what many of us crave, but seldom receive? Sure, many of us are "doing our own things", but many of us also take the time to share our (often widely-diverging) opinions about all manner of things, often at great length and in great detail. With few exceptions however, Project feedback is largely ignored, or is at best very cursory.

BTW tom in an earlier post you mentioned about trying to persuade people ... which was ultimately "in vain". There's nothing wrong with putting forward your point of view, but I've quickly come to the realisation that many, if not most, people are unlikely to be persuaded because assembly language programming (especially) is a very personal if not individual thing.

Tomasz's stated occupation, Assembly Artist, contrasts well with your "scientific" approach i.e. is it Art, or is it Science ?? I can say that, like you, I'm also heavily leaning towards (no, probably firmly embedded in!) the scientific end of the spectrum...



edfed, I'll get back to you soon ...

_________________
FAMOS - the first memory operating system
Post 19 Sep 2008, 02:59
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: 17667
Location: In your JS exploiting you and your system
revolution
neville wrote:
But, dammit, can't anybody give a guy some honest well-considered feedback on their Pet Projects around here Question
Am I right in thinking that honest well-considered feedback about our projects is what many of us crave, but seldom receive? Sure, many of us are "doing our own things", but many of us also take the time to share our (often widely-diverging) opinions about all manner of things, often at great length and in great detail. With few exceptions however, Project feedback is largely ignored, or is at best very cursory.
We all have to allocate our time in ways that sometimes does not allow us the luxury of testing everyones hobby OS to the detail that it may deserve. If you can provide a "killer app" then people would be more interested in testing your OS. Try to think of some purpose for the OS other than just for the challenge of making it. When people see a larger purpose they might find it worthwhile to allocate more time towards this particular OS and away from other OS's also on this board (and other boards).

Try not to be put off by minimal response, it is normal for most projects. Once you have brought the OS up to a level where people can start to use it for themselves then the feedback will come in due course.
Post 19 Sep 2008, 05:25
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
thanks revolution, I know good advice when I hear it Smile

At the momemt FAMOS has several "killer apps": a selection of "old favourite" games all in memory and ready to run immediately on boot-up Cool
Including Space Invaders, Tetris, PacMan, Snake and Othello - and heaps more. Plus lots of video effects and there's also some surprise packages available for loading from the disk.

But that one irresistible killer app still eludes me, unless anybody needs an Arbitrary Function Generator which generates 32 8-bit waveforms on the parallel port, plus a user-definable waveform which can be edited on the fly! (It's also on the boot disk).

_________________
FAMOS - the first memory operating system
Post 19 Sep 2008, 07:14
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
By popular (1 person Wink ) request: FASMR.ZIP attached

FASMR is a DOS Low-Memory Version of FASMF

ZIP includes FASMR sources, test source HELLO.ASM and source loader LSR.

Sample run:

Code:
C:\FASMR>lsr hello.asm

 Load DOS file to 16-bit memory, by Neville Watkin
   Loading source to memory
    start address: 00080000 Hex
   finish address: 00080855 Hex
    bytes written:      856 Hex
                       2134 Dec

C:\FASMR>fasmr

 FASM 1.48 by Tomasz Grysztar, DOS Low Memory Version by Neville Watkin

  Flat Addresses (hex):
  ~~~~~~~~~~~~~~~~~~~~
  Pre-processed Source: 50000
 Assembled Binary Code: 60000
           labels_list: 7FFA0
  Original Source Code: 80000
 DOS execution address: 26250
successful    

Now the binary output at 60000h = 5FF0:0100h can be checked using DOS Debug:

Code:
C:\FASMR>debug
- rcs
cs:xxxx
5ff0
u       ;disassemble the assembled code
g    ;run it (stops at built-in breakpoint)
dcs:100 ;display the code
q    ;done    

edfed, if this helps do what you want, I hope you'll share the results with us.
Let me know if I can help more.

Beware: mostly I don't bother asking DOS for memory - I just take it. Usually it's above 1MB so I make sure DOS doesn't even know about it, but not in this case!


Description: Low Memory Only Version of FASM 1.48 for DOS
Download
Filename: FASMR.ZIP
Filesize: 72.85 KB
Downloaded: 243 Time(s)


_________________
FAMOS - the first memory operating system
Post 19 Sep 2008, 10:46
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
tom: Yes, for development it is partially true. Doing it too fast can result in complete mess. But in this case, it was looking for bug. You don't need lot of planning for that: you know what code is supposed to do, so just fire up debugger, and look for place where expectation differs from reality.

But on the other side, "start big" overplanning is not good either. In more complicated problems, you can NEVER think of all possibilities in advance, so those plans would need to be changed anyway, creating mess too. Best way IMO is somewhere in the middle, to prepare idea in broader terms, start small, and finish details "on the run", when you see actual requirements, not just those you can think of ahead. And you must always be prepared for big "rewrites" and "redesigns", that is the *only* way to keep application code really clean. I have couple of friends who work in conditions where they "start big" and plan everything ahead, and result is that they need to change their plans anyway, as practice shows something they didn't consider. Also many "later changes" would require to change that plan anyway, so anyway, big planning doesn't save you.

About documentation, I agree. I think my FASMLIB code, my job code, and code I write with Don are all documented good enough to be easily understood by anyone who knows used programming language. Of course, insane coments like following only reduce readability, as expecting reader to know language is sane:
Code:
 inc eax ;add 1 to eax    
Post 19 Sep 2008, 10:53
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
neville wrote:
...Because FASMF hasn't generated much interest so far, I won't bother posting the bugfix unless somebody asks for it...
Yes, and someone requested it....
neville wrote:
By popular (1 person ) request: FASMR.ZIP attached
Hmm.???
vid wrote:
...insane coments like following {inc eax ; add 1 to eax} only reduce readability, as expecting reader to know language is sane:
No my friend, you COMPLETELY misunderstand me.
It is not the case that I am asking you to explain what inc eax means.

What I am asking is that you explain WHY you are incrementing eax. Of course, if eax functions as a simple loop counter for some task, even then, a comment would not be necessary. But, suppose you were testing uefi, and needed to create a bit pattern to serve as a mask for some purpose, it seems to me not inappropriate, to explain WHY you choose that particular method, of creating the mask, rather than some other, to accomplish the same goal. Where it is critical to comment code, is the situation, which occurs FREQUENTLY with much of FASM, that concurrent with execution of certain instructions, changes in flags take place, but without comment, so that there is an IMPLICIT change in program flow, without accompanying explanation of the logic governing this flow.
In vid's example, inc eax, has no effect on the CF flag, (as does the functionally identical add eax, 1 instruction), so that if one or two or three instructions later, when an explicit, or implicit evaluation of the cf flag occurs, the program could take a different track, based upon the condition of the cf flag, in such a scenario, one ought to comment as follows:

add eax, 1 ; n.b. cf flag set. *****nota bene: to me, this is NOT banal

Of course, one can argue, and who can disagree, that ONE OUGHT TO KNOW each and every flag set/reset condition, so that simply glancing at the instruction itself should suffice, without comment, but I am arguing that where program flow is concerned, one MUST comment, if one is creating a PROGRAM, instead of CODE.

I do not agree that I am demanding banality, as one readily infers, from your illustration, which seeks to trivialize my point of view.

Others may disagree, and argue against my position, that if one really has command of the instruction set, and cpu architecture, then, one needs no comments at all, to envision program flow. For that group of people, yes, my demand, in essence, is constraining productivity, because such people are compelled to waste valuable time documenting things that I ought to know, according to their own skill level (and not mine, obviously!!!!). (I have played in professional chess tournaments with people who were blind, (and lost, of course!) folks who had no need to see the chess board, in order to play tournament level, competitive, professional chess, and win. They could envision all the pieces, and all the squares, just fine, without vision, just as vid and Tomasz can "see" the entire program flow, without need to explain it.

When I shoot freethrows in basketball, I do not look at the rim, but rather, to the astonishment, (consternation, and dismay!) of my fellow teammates, at my feet on the floor, instead--and I achieve the identical (mediocre) performance as when I look at the basket.

Much of FASM is undocumented, hence my question to neville, seeking to learn how he was able to modify FASM, for his own purposes....was it easy? was it tricky? was it effortless....?
Sounds to me, as though it was relatively easy, judging from Neville's remarks, but, perhaps I have misunderstood.

Regarding vid's comment that folks who "start big", plan ahead, and then discover that they didn't consider every last detail, and must therefore change the overall program design, ANYWAY, (i.e. presumably, the same end result as if they had simply jumped in and started "coding" straight away), I submit that most of the time, such efforts, even if leading to complete rewrites, are nevertheless far superior, in the long run, to the quick and dirty methods employed by "coders", who achieve an end result MUCH FASTER than the methodical, laborious, tedious method I espouse, but, in the final product, one method leads to an immutable, unchangeable piece of code, understood ONLY by that single programmer, and in the other, i.e. the "scientific" approach, one has a PROGRAM, which ANYONE can understand, and modify, in accord with the circumstances.
Smile
Post 20 Sep 2008, 00:42
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
a code snippet (sorry, totally uncommented) Wink

Code:
  CMP     BYTE[IGNORE_POSTS_FROM_NEVILLE],1
   JZ      IGNORE_TOM
  MOV     BYTE[IGNORE_POSTS_FROM_TOM],0
       MOV     ESI,MSG_4_TOM
       CALL    POST_MSG
    JMP     NEXT_POST
IGNORE_TOM:    
    MOV     BYTE[IGNORE_POSTS_FROM_TOM],1
NEXT_POST:    

_________________
FAMOS - the first memory operating system
Post 20 Sep 2008, 03:38
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:  


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