flat assembler
Message board for the users of flat assembler.
Index
> Main > Memory Version of FASM - first step of FASM port to FAMOS |
Author |
|
neville 11 Sep 2008, 21:08
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 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 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... 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 !
_________________ FAMOS - the first memory operating system |
|||||||||||
11 Sep 2008, 21:08 |
|
edfed 14 Sep 2008, 09:38
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. |
|||
14 Sep 2008, 09:38 |
|
neville 14 Sep 2008, 23:08
edfed wrote: maybe you should not code fasmf for flat rm, but pure RM. OK, maybe pure real mode will make it easier for people to test it? But I doubt it will fix the DD problem... 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 |
|||
14 Sep 2008, 23:08 |
|
neville 18 Sep 2008, 03:07
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
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 |
|||
18 Sep 2008, 03:07 |
|
tom tobias 18 Sep 2008, 09:17
neville wrote: ...I won't bother posting the bugfix unless somebody asks for 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. |
|||
18 Sep 2008, 09:17 |
|
neville 18 Sep 2008, 11:00
Ok Tom (deep breath ), 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 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! _________________ FAMOS - the first memory operating system |
|||
18 Sep 2008, 11:00 |
|
vid 18 Sep 2008, 12:12
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 |
|||
18 Sep 2008, 12:12 |
|
tom tobias 18 Sep 2008, 17:24
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? 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 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... |
|||
18 Sep 2008, 17:24 |
|
edfed 18 Sep 2008, 18:04
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 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! |
|||
18 Sep 2008, 18:04 |
|
neville 19 Sep 2008, 02:59
tom, your questions are welcome, and of course I will answer them, but I'm less than impressed with the quality of your feedback
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 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 |
|||
19 Sep 2008, 02:59 |
|
revolution 19 Sep 2008, 05:25
neville wrote: But, dammit, can't anybody give a guy some honest well-considered feedback on their Pet Projects around here 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. |
|||
19 Sep 2008, 05:25 |
|
neville 19 Sep 2008, 07:14
thanks revolution, I know good advice when I hear it
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 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 |
|||
19 Sep 2008, 07:14 |
|
neville 19 Sep 2008, 10:46
By popular (1 person ) 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!
_________________ FAMOS - the first memory operating system |
|||||||||||
19 Sep 2008, 10:46 |
|
vid 19 Sep 2008, 10:53
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 |
|||
19 Sep 2008, 10:53 |
|
tom tobias 20 Sep 2008, 00:42
neville wrote: ...Because FASMF hasn't generated much interest so far, I won't bother posting the bugfix unless somebody asks for it... neville wrote: By popular (1 person ) request: FASMR.ZIP attached vid wrote: ...insane coments like following {inc eax ; add 1 to eax} only reduce readability, as expecting reader to know language is sane: 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. |
|||
20 Sep 2008, 00:42 |
|
neville 20 Sep 2008, 03:38
a code snippet (sorry, totally uncommented)
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 |
|||
20 Sep 2008, 03:38 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.