I did not say it could be made general, or optimal, if you cannot move the stack around, or your CPU has an internal stack(and a single register!), that's a big limitation.

Quote:

# Stack:

* The hardware call stack is so small that program structure must often be flattened
* The hardware call stack is not addressable, so pre-emptive task switching cannot be implemented
* A software-implemented stack cannot be implemented efficiently, so it is difficult to generate reentrant code and support local variables

So I see your problems, but it doesn't appear to be impossible, just impractical for general cases.

It is not usable for anything, but I would believe something like this would be possible in any processor?

start: RT1(1)
RT2(1)
RT1(2)
RT3(1)
...
jmp start

Each routine would store the data needed to stay working in known memory locations. As long as the routines didn't need a growing stack, they would be safe. Of course, you wouldn't be able to switch priorities at runtime. Correct me if I am wrong.

If you have a memory, and you have pointers, you can build a stack -- what's so special about the hardware stack (besides obvious speed or size optimizations)?

so it isn't impossible at all

Hehe, sure we could simply make a VM and run any arbitrary code. But with the smaller MCU's it might be tricky to squeeze in a VM and another OS inside the VM all within 512 program words and 64 bytes of RAM.

23 Mar 2008, 13:45

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo

DOS386 wrote:

rugxulo wrote:

yes DOS can multitask (DesqView, DR-DOS, Win 3.x)

Not DOS

Eh? How is DR-DOS not DOS? Even DesqView should count as it's just a program. Win 3.x? Okay, maybe not pure DOS, but still ....

DOS386 wrote:

Quote:

nice job, but why is the example so, er, useless? Creating a 40 MB file?? I mean, I assume you have a reason, but still

1. Examples are usually "useless"
2. Creating a huge file ... to get time for showing the progress indicator
3. Should I create an example of progress indicator applied to a sophisticated compiler, compressor, brutal-forcer instead ? An "example" with several 10'000's lines ?

1. I meant that creating 40 MB file isn't as useful as your other examples.
2. Yes, I see that.
3. No, it doesn't have to be that complex. You could integrate the progress thingy inside something small like xWCopy perhaps??

24 Mar 2008, 03:16

DOS386

Joined: 08 Dec 2006
Posts: 1901

DOS386

> Eh?

There is no "eh". Note where I cut the quote. Dr-DOS is DOS,
but I still don't like it's DREMMM386

> Win 3.x? Okay, maybe

Very sure not

> 3. No, it doesn't have to be that complex. You could integrate
> the progress thingy inside something small like XWCopy perhaps ?

YES. FYI, I have been working on porting it to FASM that time.
Did you do apply any changes except porting to NASM ?

Last edited by DOS386 on 24 Mar 2008, 08:41; edited 1 time in total

24 Mar 2008, 08:22

DOS386

Joined: 08 Dec 2006
Posts: 1901

DOS386

> Also, why do you put "define pope pop"? Why not just use "pop reg" and
> replace "pope" with "pop" in your code?

But then I would have to "define pus push"

> Any system that supports interrupts can theoretically do multitasking,
> just save state and jump to another thread or task when a certain interrupt occurs.

Exactly.

I've seen many attempts to do MTSK, but none of them was really good. Either do
it well, or don't do it at all

24 Mar 2008, 08:38

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo

DOS386 wrote:

> 3. No, it doesn't have to be that complex. You could integrate
> the progress thingy inside something small like XWCopy perhaps ?

YES. FYI, I have been working on porting it to FASM that time.
Did you do apply any changes except porting to NASM ?

Well, it originally was 386+ and yet used very very very little 386-specific instructions that I decided (with help of Eric Auer) to convert it to 8086. In fact, I had previously converted it to FASM, but for this version I chose NASM only because there's an old 16-bit NASM still available on SourceForge, and I figured some people (ahem, Trixter/8088 Corruption dude, who I also emailed) might want to tweak it.

P.S. I actually used MCD's ONLY8086.INC in my 0.7 hack, but I had to manually work around some conditional jumps that were > 128 bytes away. However, then I discovered revolution's compatibility macros. And also, NASM "-O3" does the same thing. So, if it weren't for trying to be nice to potential 8086 developers, I would've definitely used FASM again. (For revolution's macros, you have to use ".086" explicitly for the jumps to be automagically tweaked.)

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum