flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3 Next |
Author |
|
neville 28 Jul 2008, 20:10
Tomasz Grysztar wrote: Look into the sources - you can see it for yourself. Thank you again Tomasz, I will certainly be looking at your sources in detail because I want to port FASM to FAMOS, as part of my proposed FAMOS 32-bit IDE. And if I find any recursive code I will scratch it out and banish it into oblivion forever, never to be seen again. ![]() ![]() So I will make a memory version of FASM which will read the input source directly from memory, and output the binary straight to memory also. This will be integrated with my text editor, my 32-bit memory editor and other utilities. Then I will be able to develop FAMOS entirely in FAMOS which I see as a significant milestone for any new OS. (but I still can't see how using INCLUDE directives could produce recursive code?) _________________ FAMOS - the first memory operating system |
|||
![]() |
|
neville 28 Jul 2008, 20:57
bitRAKE wrote: How is this article anything but a warning against call overhead being greater than the function being executed in the call? Don't lose sight of the fact that if your code executes a recursive loop enough times then it WILL cause a stack overflow. No doubt about it. The linked article clearly shows the stack overflow problem - it occurred in EVERY case. So unless you then write a special stack overflow error trap (or use an OS with one built-in), you could never guarantee your recursive code won't cause a total system CRASH. Of course the error trap would really just be a "sticking plaster" on the problem. Imho it's better to write code which eliminates as many failure modes as possible. _________________ FAMOS - the first memory operating system |
|||
![]() |
|
Borsuc 28 Jul 2008, 21:02
For me "traditional" recursion is again, silly. It pushes the return address on the stack, and makes 100000 copies of it... Completely useless, especially if you have more parameters that don't change
![]() |
|||
![]() |
|
neville 28 Jul 2008, 21:32
to edfed:
OK, so your code becomes recursive for the one case when eax=node. But do you actually want "node" to execute itself?? BTW, why do you use jl/jnl instructions? I assume your stored addresses are not signed data? In which case there are times when your code might fail, but not because of recursion. ![]() to The_Grey_Beast: Well said. It's always nice to know one isn't totally alone in this harsh world ![]() _________________ FAMOS - the first memory operating system |
|||
![]() |
|
edfed 28 Jul 2008, 23:29
to edfed:
OK, so your code becomes recursive for the one case when eax=node. But do you actually want "node" to execute itself?? of course i want it, it is the only way i found to manage "infinite" node's chains. each recursion cost something like 16 stack (ss;esp) bytes ( including objet stack usage) and my PC have 256 Mbytes of ram. then, at least a very² big² program. recursion, using my node func, will be cutted, each node can contain up to a lot of nodes, etc etc... but when ypou quit a ,ode, you lose the stack of this node, and replace it with next node or object. there are many possibilities to have recursion with multiple ends. for example, a simple recursion using a flag. Code: mov edi,where you want mov ax,in the segment you want mov es,ax ;because it is like that. xor ebx,ebx @@: or eax,eax je @f call @b mov eax,[es:edi] ret @@: inc ebx ret this thing will end only when dword [es:edi]=0 and an extra feature, you will have the number of recursions before to meet the right state to exit. or the end of a recursional file encapsulation. like the thing in test section... if it is in the keyboard buffer, it can be the time without any keypress. but i don't see the usage. how long did you code in asmx86 with fasm before to loggin? what hav you made using assembly, x86 or else? bye bye...see your comment tomorrow.thread killer jl jle are for a special security feature, if for any reason, an address is negative, it will ignore it. then, i restrict my address space to 2 GBytes istead of the 4 usual Gbytes. but it is not important, the essensial is to be sure to quit the loop. if eax-1<0, then, there is no items at all, and decrement because we use at least one item if it is ok. if eax-1=<0 then, there are no moe items, or it is the last one, then, don't reloop. all this recursion sheme assume you still have nodes, objects and functions to make it. something like this: Code: include 'comheader.inc' desk dd shell shell dd f.gnode,0,0,320,200,@f-$-4 dd .refrsh dd .reply dd .parse dd prompt dd 0;help dd browser.view dd 0;.box dd 0;keymap dd 0;time_stamp_counter dd clock dd calendar dd 0;calculette dd .kb dd .init @@: .init dd f.asm,movmod,.raz .raz dd shell+item.data+4*2,0 .xorer dd shell+item.data+4*2,.parse .box dd f.box,-1,-1,1,1,Maroon .parse dd f.parse,prompt.input,comtable .refrsh dd f.refresh,Gray .kb dd f.key,0,@f-$-4 dd .otk @@: .otk dd kb.otk,0,@f-$-4 dd key.enter,xormod,.xorer dd key.numenter,xormod,.xorer ; dd key.echap,incb,exit dd key.verrmaj,shelltoogle,0 @@: .bbox dd f.node,0,0,300,200,@f-$-4 dd .box @@: .reply dd f.txt,4,190,0,0,null;pathbuffer db Silver,Navy,0,0 dd font85 calendar: dd f.gnode,230,190,0,0,@f-$-4 dd .text,.hex,.date @@: .date dd f.date,2000h .hex dd f.numhex dd @f dd .date+4,.nh0-@f @@: rb 4*2 .nh0: db 0 align 4 .text dd f.txt,0,0,0,0,@b db blue+8,Silver,0,1 dd led85 clock dd f.gnode,280,190,0,0,@f-$-4 dd .text,.hex,.time @@: .time dd f.time,0 .hex dd f.numhex dd @f dd .time+4,.nh0-@f @@: rb 3*2 .nh0: db 0 align 4 .text dd f.txt,0,0,0,0,@b db red+8,Silver,0,1 dd led85 codepage: dd azerty include 'applications/keymap.inc' include 'applications/rdtsc.inc' include 'applications/prompt.inc' include 'applications/browser.inc' include 'applications/fright.inc' include 'applications/calculette.inc' help dd f.gnode,4,2,(prompt.end-prompt.prompt+1)*6,180,@f-$-4 dd .txt,.box,.keyb @@: .keyb dd f.key,0,@f-$-4 dd .tmk @@: .tmk dd kb.tmk,0,@f-$-4 dd key.up,scrollu,.txt+item.txt dd key.down,scrolld,.txt+item.txt @@: .box dd f.box,0,0,(prompt.end-prompt.prompt+1)*6,180,green+10 .txt dd f.txt,3,2,(prompt.end-prompt.prompt+1)*6,180,@f db 0,Silver,0,1 dd font85 @@: db 'Help!!!!! CTRL + SHIFTLOCK toogle the prompt',10,13 db '',10,13 db '',10,13 db 'exit ==> Quit the shell',10,13 db 'box x,y,xl,yl,c ==> Change the main box',10,13 db 'color c ==> Change background color',10,13 db 'path ==> Set prompt to current path',10,13 db 'null ==> Hide the reply item',10,13 db 'keyb codepage ==> Set keyboard to fren or engl',10,13 db '',10,13 db 'help ==> Toogle this help',10,13 db 'keymap ==> Toogle the keymap',10,13 db 'rdtsc ==> Toogle the rdtsc window',10,13 db 'feeble ==> Toogle the html parser',10,13 db 'time ==> Toogle the time view',10,13 db 'date ==> Toogle the date view',10,13 db '',10,13 db 'hello',10,13 db 'bonjour',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 db '.',10,13 dd 0 shelltoogle: test byte[key+key.status],key.ctrl? je .end xor byte[key+key.status],key.shiftled xor dword[shell+item.data+4*3],prompt xor dword[shell.otk+kb.data+4*0],key.enter xor dword[shell.otk+kb.data+4*1],key.numenter .end: call kb.ledupdate ret pathbuffer db 'fda/' rb 100h align 4 |
|||
![]() |
|
neville 29 Jul 2008, 10:06
rugxulo wrote: Isn't this the old "recursion vs. iterative" argument we've seen before? Do you recall where the thread was? It would be interesting to see any past opinions _________________ FAMOS - the first memory operating system |
|||
![]() |
|
neville 29 Jul 2008, 10:35
to edfed:
Your shell code makes my brain hurt to figure it out ![]() Your security feature is a novel idea! I've been coding now for 29 years. Since before the PC. Started on 6800, then Z80 systems, then X86 later. Mostly for hardware interfacing apps, like data logging etc. Some HLL, but mostly always asm. Remember edtasm for the TRS80? My interest is really hardware engineering, so I like to know exactly what the CPU is doing, all the time. The only way is to write my own OS. That's one reason why I developed FAMOS. I found FASM when I was looking for a 32-bit assembler about 7 years ago but the version I got (1.30) didn't support upper case source. So I never used it, then I discovered Tomasz added upper case support and I started using it about 4 years ago, but mostly in the last couple of years. It is great! On X86 my development platform has always been DOS. Have done no Windows development. Hope this answers your questions! _________________ FAMOS - the first memory operating system |
|||
![]() |
|
tom tobias 29 Jul 2008, 13:13
edfed wrote: ...everybody use recursion, they not see it everytime, neville, responding to rugxulo's accurate perception that this topic had been discussed previously, wrote:
edfed, tom, and vid wrote: about recursion in the context of operating system development ![]() |
|||
![]() |
|
neville 29 Jul 2008, 20:58
Quite so Tom, although maybe some more definition of "stack programming" is needed. Recursion often leads to "unintended" stack programming which is undocumented as you say. But I say there is nothing wrong with "deliberate" stack programming for a variety of purposes. Many HLL compilers of course prefer to used the RAM-based stack for all parameter passing; after all that's essentially what Intel originally intended the SS:BP register to be used for. And of course complex stack manipulations are used by many software companies purely for anti-piracy reasons!!
Also programming the FPU or NDP is necessarily "stack programming", except the stack is register-based rather than RAM-based. And I do agree that any "recursive" internal CPU hardware implementations are irrelevant to the merits or otherwise of recursive programming (if that's what you meant). Thanks for the link to thread 7808. There's less about recursion than I thought, but nonetheless a very interesting discussion about OS development issues, including paging and parameter passing. I agree with you that passing parameters via fixed memory locations is feasible even in a multi-tasking environment. In my experience, quite often the "conventional wisdom" is wrong. So to edfed: How is your OS now - is it still in progress? _________________ FAMOS - the first memory operating system |
|||
![]() |
|
edfed 29 Jul 2008, 21:58
Quote: How is your OS now - is it still in progress? boot loader use boot objects to load sectors for kernel loading. when you exit the code loaded as a kernel, computer will reboot from the drive 80h. the kernel can be any .com code, the size is limited to 64kb. all the kernel is based on objects. i am planing the file open function and the read sectors command. there is a lot of recurssive code inside... when it bugs, it can be hardcore. delete all the drive, or crash it ZZZZZzzz it is a strange system. maybe too lazy to code. i have a bug using computed recursions. the objects are data structures used as parameters for a function. theses datas are R/W for me. Code: fright dd f.gnode,5,5,310,190,@f-$-4 dd .1 dd .box dd .asm dd .init @@: .init dd f.asm,@f @@: mov dword[.1+gnode.data],.1 mov dword[.1+box.xl],300 mov dword[.1+box.yl],180 ret .1 dd f.gnode,5,5,0,0,@f-$-4 dd .1 dd .box dd .asm @@: .asm dd f.asm,@f @@: mov ecx,[edi+box.xl] mov edx,[edi+box.yl] sub ecx,10 sub edx,10 mov [box+box.xl],eax mov [box+box.yl],ebx cmp dword[edi+box.x],40 jl @f xor byte[.box+box.c],0ffh ret @@: mov dword[.1+gnode.data],0 ret .box dd f.box,0,0,0,0,0 Here, the bug is simple, it will exit the application, or freeze it. as a result, the screen will be coloured with recursive boxes. but it don't works. if it works as a simple effect, it can work as a sequenced or mathematical effect... and with other things than boxes. it is not really an os, but a librairy to have a set of predefined functions, and a frame to code interconnections with asm, all with a single tool. about multitasking, i can save µP context as a fool object, then, it can become a way to make network multithread independent of the machine family ( not for now for sure) |
|||
![]() |
|
neville 30 Jul 2008, 06:57
edfed wrote:
Quote: there is a lot of recurssive code inside... lol that's very funny!! ![]() The old cursed recursed code huh? It's what I've been saying for a while now... ![]() _________________ FAMOS - the first memory operating system |
|||
![]() |
|
sinsi 30 Jul 2008, 07:02
neville: so show me a way of listing directories and subdirectories without using recursion.
|
|||
![]() |
|
Tomasz Grysztar 30 Jul 2008, 08:01
sinsi wrote: neville: so show me a way of listing directories and subdirectories without using recursion. In assembly language you always can get rid of recursion, if you really want - as The_Grey_Beast pointed out earlier in this thread (however he did not mention the more complex case, when there is more than one function, each calling each other). Anyway recursion sometimes makes code more nicely structured - that's the main reason why I have used it in fasm's core. |
|||
![]() |
|
neville 30 Jul 2008, 10:34
Tomasz Grysztar wrote: Anyway recursion sometimes makes code more nicely structured - that's the main reason why I have used it in fasm's core. And I'm very glad you created fasm's core (so who cares about a little recursion here and there ![]() I agree that recursion can certainly make code shorter, and make it look more nicely structured, even more elegant some would say. But only from a "human" perspective I suggest. From the CPU's point of view, executing recursive code is almost always more work and therefore takes longer, and even longer still if the equivalent iterative code was mainly register-based, with minimal memory accesses. With a RAM-based stack, recursive code has constant memory accesses. to sinsi: Quote: neville: so show me a way of listing directories and subdirectories without using recursion. As Tomasz says, it can be done. In FAMOS I can read the directories and sub-directories from ISO9660 CD's and translate them into FAMOS 128-byte Disk Contents Database records, complete with their dates, times and long names. And no recursion to be seen ![]() _________________ FAMOS - the first memory operating system |
|||
![]() |
|
f0dder 30 Jul 2008, 11:09
sinsi wrote: neville: so show me a way of listing directories and subdirectories without using recursion. Not really sure if there's much advantage to the method, since you're still using an unknown amount of memory, and you'll probably be relying on heap allocations which are slower than simple stack allocations. Then again, you'll be bound by I/O speed, so that's pretty irrelevant. Oh, and some of the other posters seem to ignore that you don't have to stack-overflow, you can control maximum recursion depth and exit gracefully. Besides, you don't necessarily need deep recursion. And there's all sorts of clever things you can do, for instance check the non-recursive version of qsort() in MS's libc. I'm not a big fan of functional programming languages (I'm just not that much into math and puuuuurity), and often find that iterative code is simpler to follow. But still, consider what tail recursion can do for you. Some of you seem too caught-up in the "recursion MUST mean push/call/allocate-stack-for-locals overhead!", which isn't necessarily true. _________________ ![]() |
|||
![]() |
|
tom tobias 30 Jul 2008, 12:59
Tomasz wrote: Anyway recursion sometimes makes code more nicely structured - that's the main reason why I have used it in fasm's core. Then, one can conclude that there is nothing INHERENTLY recursive about design of either the algorithm or the data structures employed in FASM. Recursion, in the case of FASM, at least, has been chosen, NOT because an assembler requires it, but for, essentially, esthetic purposes.
The question for this FASM forum thread then arises: Can we request an illustration, of a single instance in any part of the FASM algorithm, or data structure(s) which are MORE comprehensible, or MORE easily understood, (hence, more easily modified!!!) BECAUSE they are created with recursion, rather than iterative technique? One may suppose that defending Tomasz' notion could easily represent a useful Doctoral thesis in a department of Computer Science:
Perhaps Tomasz has data, i.e. FASM, to repudiate this notion, thus, he may well possess the essential ingredient for any doctoral dissertation, i.e. an issue, considered resolved by the academic community, which is then repudiated by some novel design, or novel experiment, in this case: FASM. What is a program? According to Niklaus Wirth's famous book from 1975, (of the same title!!) A program = algorithm plus data structure(s). What is the distinction between an iterative and recursive program? Why is the iterative (or recursive) form preferred, (when compared to the other,) in a structured milieu? What advantage accrues, in an Assembly language programming environment, to use of iteration versus recursion? All of these questions, related to the central theme underlying Tomasz' comment, can be addressed in preliminary sections of such a doctoral dissertation. While such topics may be understandably considered uninteresting to mathematicians, they remain on the agenda of computer scientists, hence, available for anyone to tackle. This topic--structured recursive programming--remains one of keen interest, even today, nearly half a century after the first papers appeared on the subject. this conference wrote:
These enthusiastic supporters of using recursion in writing computer programs may be correct (in some abstract definition of "correctness",) but, are these same capabilities ("tools of remarkable power and abstraction") available for those developing (and in particular, DEBUGGING,) Assembly language programs? I claim the opposite. I deny any value to recursive definitions of either data structures or algorithms. I deny that FASM is superior in design because it employs recursion. For one thing, a recursively defined data structure assumes potential for a limitless quantity of memory, an unrealistic scenario, which certainly ridicules the notion of "structured programming", a central tenet of which is that DEFINITION of the data structure represents a rigorous prerequisite to writing any code. To my way of thinking, recursion is the antithesis of structured programming, for recursion demands OPENENDEDNESS. Limitlessness. No Borders. No boundaries. That idea, recapitulating capitalism, and repudiating socialism, is applauded by coders, not programmers. USA is overflowing with universities instructing students to think in a similar fashion. Only a few, rare, old geezers taught the contrary. One of them was Donald Knuth. A paper written by Niklaus Wirth, under his name, Structured Programming with GoTo statements, was described this way: An analyst of Knuth's paper wrote:
In addition to repudiating recursion, at least in an assembly language programming environment, Knuth also includes MANY excellent references, including Dijkstra's classic paper in addition to others by Wirth, Hoare, McCarthy, Naur, Backus, Bauer, and many, many others. These debates have gone on for decades. FASM forum could provide a useful contribution to this debate by offering, instead of platitudes, generalities, and references, ACTUAL CODE, demonstrating the inherent "POWER, and ABSTRACTION" which emerges from comparing side by side FASM first, as it is now, recursively written, and then, (for that small illustrative snippet,) rewritten iteratively, demonstrating how clumsy, inefficient, and time consuming the iterative solution appears. I doubt such a scenario. I guess that the only difference between the iterative translation, and the recursive, currently extant version, will be one of READABILITY associated with a properly documented iterative version, compared with the inscrutability of the existing (recursive) code. Both snippets of code will execute very quickly, and the time savings of an iterative or recursive approach would not be of importance to such an exercise. The snippet of code need not lengthly: 10-20 lines, maximum, though, admittedly, the existing recursive snippet could well expand into a MUCH LONGER version, when converted to iterative form. fodder wrote: Some of you seem too caught-up in the "recursion MUST mean push/call/allocate-stack-for-locals overhead!", which isn't necessarily true. |
|||
![]() |
|
comrade 30 Jul 2008, 13:26
Who cares? Its the same thing. Just instead of using the CPU's stack (esp) you use your own stack (your graph data structure or whatever). Who cares? If the algorithm says you need to evaluate multiple conditions (which looks like a tree if you graph it), then it is recursion, nevermind whichever way you implement it.
|
|||
![]() |
|
Borsuc 30 Jul 2008, 14:50
comrade wrote: Who cares? Its the same thing. Just instead of using the CPU's stack (esp) you use your own stack (your graph data structure or whatever). Who cares? If the algorithm says you need to evaluate multiple conditions (which looks like a tree if you graph it), then it is recursion, nevermind whichever way you implement it. ![]() |
|||
![]() |
|
f0dder 30 Jul 2008, 17:51
The_Grey_Beast: how deep recursion would you need to traverse a balanced binary tree with 2^32 nodes?
![]() |
|||
![]() |
|
Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.