flat assembler
Message board for the users of flat assembler.

Index > Main > A bit of programming styles

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
Quote:

And in ASM, I can't think of any application where recursion could really be justified, except maybe in some fancy game graphics, eh bitRAKE


fatal error!
everybody use recursion, they not see it everytime, but we all use recursion.
there are some recursive hardware in the x86, like latches, memory, nested interrupts, etc etc...

and maybe you don't know that, but everytime there are nodes somewhere, there are recursions.

for example, my simple node function, to execute every items inside the node, one by one, starting by the last one.
Code:
node:
.call=0
.size=4
.data=8
;edi is the parent item
;esi is the current item
        push edi
        mov eax,[esi+.size]
        shr eax,2
        dec eax
        jl .end
        mov edi,esi
.next:
        push eax edi
        mov esi,[edi+eax*4+.data]
        or esi,esi
        je @f
        mov eax,[esi+.call]
        or eax,eax
        je @f
        mov eax,[eax]  
        or eax,eax
        je @f
        call eax   ; what will happen if eax=node?
@@:
        pop edi eax
        dec eax
        jnl .next
.end:
        pop edi
        ret
    
Post 28 Jul 2008, 16:32
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
Tomasz Grysztar wrote:
Look into the sources - you can see it for yourself. Wink

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

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
Post 28 Jul 2008, 20:10
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
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
Post 28 Jul 2008, 20:57
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
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 Confused
Post 28 Jul 2008, 21:02
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
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. Wink

to The_Grey_Beast:
Well said. It's always nice to know one isn't totally alone in this harsh world Wink

_________________
FAMOS - the first memory operating system
Post 28 Jul 2008, 21:32
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
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
    
Post 28 Jul 2008, 23:29
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
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
Post 29 Jul 2008, 10:06
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
to edfed:
Your shell code makes my brain hurt to figure it out Wink

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
Post 29 Jul 2008, 10:35
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
edfed wrote:
...everybody use recursion, they not see it everytime,
I believe that neville was (accurately, in my experience) describing the arduous task of debugging software based upon stack programming, which is often UNDOCUMENTED, hence, more easily thrown in the trash, than debugged. Accordingly, the transparent operations of the cpu are irrelevant to the topic of discussion.
neville, responding to rugxulo's accurate perception that this topic had been discussed previously, wrote:

Do you recall where the thread was? It would be interesting to see any past opinions
about recursion in the context of operating system development

Smile
Post 29 Jul 2008, 13:13
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
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
Post 29 Jul 2008, 20:58
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
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)
Post 29 Jul 2008, 21:58
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:

Quote:
there is a lot of recurssive code inside...
when it bugs, it can be hardcore. delete all the drive, or crash it ZZZZZzzz

lol
that's very funny!! Laughing

The old cursed recursed code huh? It's what I've been saying for a while now... Wink

_________________
FAMOS - the first memory operating system
Post 30 Jul 2008, 06:57
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 693
Location: Adelaide
sinsi
neville: so show me a way of listing directories and subdirectories without using recursion.
Post 30 Jul 2008, 07:02
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7718
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 30 Jul 2008, 08:01
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
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 Wink ) and fasm of course is also the reason why we're all here, having this and many other interesting discussions!

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 Wink . Does that count?

_________________
FAMOS - the first memory operating system
Post 30 Jul 2008, 10:34
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
sinsi wrote:
neville: so show me a way of listing directories and subdirectories without using recursion.
Instead of recursing, do a while-loop that fetches folder paths from a data structure (linked list, vector, whatever floats your boat). Once the structure is empty, you're done. During processing, you add found folders to said data structure.

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.

_________________
Image - carpe noctem
Post 30 Jul 2008, 11:09
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
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.


It is shown how to construct a nonrecursive routine to solve a problem whose solution is naturally recursive. This nonrecursive routine is then used as a foundation from which one can construct a simpler and better structured program than the original version.

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:

a data structure whose definition is self-referential or recursive... cannot be written in a conventional, strict, imperative programming language...

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 workshop is a forum for researchers who seek to reflect mathematical phenomena in data and control....Modern programming languages, and in particular functional languages, support the direct expression of mathematical structures, equipping programmers with tools of remarkable power and abstraction.... MSFP 2008 will be held on 6 July. This time around, we're delighted to be a part of ICALP 2008 , running 6-13 July at Reykjavik University, Iceland.

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:

In keeping with the heretical title of his paper, Knuth introduces a fourth theme: There are times when the programmer should put gotos into his code, rather than take them out. For example, gotos can be used to convert recursion to iteration;

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.
Sure, stack overflow is primarily a problem for the algorithm in recursive programming, not for elaboration of the data structure. Was Tomasz referring to the FASM algorithm? I suppose not. My guess, in ignorance, is that he elaborates the data structure recursively.
Post 30 Jul 2008, 12:59
View user's profile Send private message Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
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.
Post 30 Jul 2008, 13:26
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
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.
Only that in the stack case you push up 10000 copies of the return address, when you already know what it is Wink
Post 30 Jul 2008, 14:50
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
The_Grey_Beast: how deep recursion would you need to traverse a balanced binary tree with 2^32 nodes? Smile
Post 30 Jul 2008, 17:51
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:  
Goto page Previous  1, 2, 3  Next

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

Powered by rwasa.