Re: [9fans] Google search of the day
On Thu, 14 Feb 2008 22:09:04 -, Pietro Gagliardi [EMAIL PROTECTED]
wrote:
Here's what I think is the best solution: statically allocate the
maximum number of tasks per process:
struct JobControlBlock { /* the name my OS uses for the info field of a
process (job) */
Task *mainTask; /* task == thread */
Task *jobTasks[400]; /* pointers to entry in an array of statically
allocated tasks */
};
A Task runs a function; it does not continue executing at the current
point. Returning from that function halts the task. Returning from the
main task halts all tasks.
That parallels Microsoft NT's concept of threads (aka, lightweight
processes):
//ThreadProc is the function the thread runs
hThread = CreateThread (security_attributes, dwStackSize, ThreadProc,
pParam, dwFlags, idThread);
Which is rather old, by the way. The same concept re-surfaced later on in
.NET as the Thread and ThreadPool classes in System.Threading namespace.
Sidenote: despite the negative hype, Windows programming is jolly merry.
Now a SpawnTask() (fork()) can only be done to create up to 400 tasks
with the exception of the main task.
As Erik Quanstrom pointed out, setting a limit for the total number of
processes/tasks/threads would create another vulnerability. That is,
inability to create any more processes because some
malicious/poorly-written process is consuming all the quota.
I am wondering which magical property of the number 400 has made it
suitable as the limit to the number of tasks. Four hundred tasks may be
amenable on your platform but wreak havoc on somebody else's poor old PC.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
[9fans] /net panic
muzgo (from irc) was playing around with /net in qemu and came across this gem: on drawterm: cpu% cd /net/tcp cpu% cat clone 23cpu% cd 23 cpu% echo connect 10.0.2.1!12345 ctl cpu% cat status Finwait2 qin 0 qout 0 srtt 0 mdev 0 cwin 1461 swin 328500 rwin 655350 timer.start 10 timer.count 10 rerecv 0 katimer.start 200 katimer.count 159 cpu% echo connect 10.0.2.1!12345 ctl cpu% this causes CPU server to reboot with: panic: timerstate1 panic: timerstate1 dumpstack disabled cpu0 exiting The usage of /net is invalid, but you wouldn't really expect that to reboot the machine (or maybe it's a holdover from before /dev/reboot existed? ;) ). Just tried it on my cpu server and got the same panic, so we can rule qemu out. I adjusted the ip!port to something that would accept my connection, and my status was something like Timedwait rather than Finwait2. Second time around I skipped the cat status and still hit the panic so the status read isn't affecting things (which is probably blindingly obvious to anyone familiar with the /net code, but oh well). I appear to be running a realtek 8169 nic: #l0: rtl8169: 100Mbps port 0xE400 irq 11: 000aeb2ff32c Don't know what muzgo was using in qemu, but let me know if I can provide any useful information. -sqweek
Re: [9fans] Google search of the day
On Fri, Feb 15, 2008 at 2:51 AM, Iruata Souza [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 3:14 PM, Eris Discordia [EMAIL PROTECTED] wrote: I think it will be possible to kill the spawned children, because they are all bound to have pids larger than a certain number. not if the pids are randomized as in OpenBSD. Easy to take care of in unix, just don't kill anything until you've suspended all the fork happy procs. Is there a fork analog in plan 9? -sqweek, who should just read proc(3) but since he's commenting anyway...
[9fans] Consindering eBox-4854 for Plan9
Hi all. I am considering purchasing an eBox IV Series box for a Plan9 installation, and I was curious of any of your successes or failures with these or similar systems. Specifications for each box in the series can be found at http://www.wdlsystems.com/downloads/specs/1EBX48T_s.pdf. The eBox-4854 is what Zombu uses for their $99 subscription machine, so I imagine it is open-source friendly enough, but I have had all manner of difficulty installing Plan9 on many machines. I recalled seeing a few posts here concerning success on VIA EPIA platforms, but not much, so I figured I would voice a few concerns and questions: The eBox-4854 box features Realtek RTL8100B 10/100 Base-T Ethernet. This is not listed on the Plan9 hardware compatiblilty page. Perusing online forums suggests that this adapter can be driven on some Linux distros with 8139too. How likely is Plan9 to similary drive this ethernet adapter? It also features integrated VIA UniChrome Pro II video to which the Plan9 hardware compatibility page suggests it can be driven in VESA mode. However, I do not know if there are key differences between UniChrome and UniChrome Pro II that would prevent this. Are there any such differences? Notwithstanding said differences, at what maximum resolution would Plan9 enable on this adapter? Rather than a traditional hard disk, the eBox-4854 fits an IDE Flash SDD. I imagine that this would pose no problem for Plan9, since such devices usually internally manage translation from Flash to standard IDE. Am I about right in this assumption? Finally, a related, but misplaced question: Does anyone know on what chipset the optional integrated wireless adapter is based? I have searched in vain. Again, it must be open-source friendly, but open- source wireless compatibility varies wildly across platforms and distributions. Thanks. I look forward to your inputs or suggestions if and when you have the inclination and time.
Re: [9fans] Google search of the day
erik quanstrom wrote: as was discussed a few months ago, any system that has unreserved stack allocation can suffer from similiar problems. the oom killer on linux is a symptom of this kind of problem. Speaking of such things: (1) Linux had/has a feature where the storage reserved by malloc/sbrk may be over-committed, so that despite a success indication from the allocation, when the application gets around to using the storage it could suddenly fail due to there not being enough to satisfay all current processes. I urged (but don't know whether anybody listened) that overcommitment should be disabled by default, with processes that want it (said to include sparse array programs, which sounds like bad design but that's another issue) being required to enable it by a specific request, or at least flagged as special in the executable object file. I kludged around this in my portable malloc implementation by having a configuration flag which if set caused malloc to attempt to touch every page before reporting success, trapping SIGSEGV in order to maintain control. (2) C, as well as many other PLs, has always had a problem in that there is no clean, standard mechanism to handle the situation in which a function invocation finds insufficient stack remaining to complete the linkage (instance allocation). This is especially problematic in memory-constrained apps such as many embedded systems, when the algorithm is sufficiently dynamic that it is impossible to predict the maximum nesting depth. At least with malloc failure, the program is informed when there is a problem and can take measures to cope with it. I hope people working on run-time environments will find ways to do better.
Re: [9fans] Google search of the day
believe it or not plan 9 does exactly the same thing, as was discussed in august under the subject plan 9 overcommits memory?. fundamentally, i think the stack problem is an operating system problem not a language problem. (unless you're talking about 8 or 16-bit embedded things.) the thread library, for example does just fine requiring its threads to declare a stack size. in the case of a memory-constrained app on an embedded system, the solution might be to find/write an algorithm that doesn't need a stack. :-) - erik (1) Linux had/has a feature where the storage reserved by malloc/sbrk may be over-committed, so that despite a success indication from the allocation, when the application gets around to using the storage it could suddenly fail due to there not being enough to satisfay all current processes. I urged (but don't know whether anybody listened) that overcommitment should be disabled by default, with processes that want it (said to include sparse array programs, which sounds like bad design but that's another issue) being required to enable it by a specific request, or at least flagged as special in the executable object file. I kludged around this in my portable malloc implementation by having a configuration flag which if set caused malloc to attempt to touch every page before reporting success, trapping SIGSEGV in order to maintain control. (2) C, as well as many other PLs, has always had a problem in that there is no clean, standard mechanism to handle the situation in which a function invocation finds insufficient stack remaining to complete the linkage (instance allocation). This is especially problematic in memory-constrained apps such as many embedded systems, when the algorithm is sufficiently dynamic that it is impossible to predict the maximum nesting depth. At least with malloc failure, the program is informed when there is a problem and can take measures to cope with it. I hope people working on run-time environments will find ways to do better.
Re: [9fans] Google search of the day
(2) C, as well as many other PLs, has always had a problem in that there is no clean, standard mechanism to handle the situation in which a function invocation finds insufficient stack remaining to complete the linkage (instance allocation). This is especially problematic in memory-constrained apps such as many embedded systems, when the algorithm is sufficiently dynamic that it is impossible to predict the maximum nesting depth. At least with malloc failure, the program is informed when there is a problem and can take measures to cope with it. I hope people working on run-time environments will find ways to do better. FORTRAN never had this problem. Its memory needs were fixed at compile time. Neither did COBOL. But then again, you couldn't write recursive programs either; all locals were static storage class. The trade off to get recursion has been worth it and doesn't cause problems actual use. It wasn't a problem with Algol, PL/1, Pascal, and C programs on very small machines. Why should it be a problem with today's memory sizes? Brantley
Re: [9fans] /net panic
On Fri, Feb 15, 2008 at 7:20 AM, sqweek [EMAIL PROTECTED] wrote: muzgo (from irc) was playing around with /net in qemu and came across this gem: on drawterm: cpu% cd /net/tcp cpu% cat clone 23cpu% cd 23 cpu% echo connect 10.0.2.1!12345 ctl cpu% cat status Finwait2 qin 0 qout 0 srtt 0 mdev 0 cwin 1461 swin 328500 rwin 655350 timer.start 10 timer.count 10 rerecv 0 katimer.start 200 katimer.count 159 cpu% echo connect 10.0.2.1!12345 ctl cpu% this causes CPU server to reboot with: panic: timerstate1 panic: timerstate1 dumpstack disabled cpu0 exiting The usage of /net is invalid, but you wouldn't really expect that to reboot the machine (or maybe it's a holdover from before /dev/reboot existed? ;) ). Just tried it on my cpu server and got the same panic, so we can rule qemu out. I adjusted the ip!port to something that would accept my connection, and my status was something like Timedwait rather than Finwait2. Second time around I skipped the cat status and still hit the panic so the status read isn't affecting things (which is probably blindingly obvious to anyone familiar with the /net code, but oh well). I appear to be running a realtek 8169 nic: #l0: rtl8169: 100Mbps port 0xE400 irq 11: 000aeb2ff32c Don't know what muzgo was using in qemu, but let me know if I can provide any useful information. -sqweek no *strange* things running, i guess. iru
Re: [9fans] Google search of the day
My understanding has always been that the stack is a fundamental element of the x86 architecture. SP and BP registers, later ESP and EBP, are all about the stack. All return addresses are stored on the stack. Parameter passing relies on it. And I know of no other means of implementing them. Except by avoiding call/ret instructions and solely jmp'ing around in a true mess of a code. No true procedures. while this is true, you are confusing calling convention and architecture. the arch puts some limits on calling convention, but there is no requirement to use the stack if you have one. you could have a calling convention that every function emits a call block with the arguments at callblock+offset and the return value(s) at callblock- offset. doesn't matter if the arch has a stack or not. you are free to ignore it. ' I am almost sure the modern incarnations of FORTRAN (90, or even 77?) do support both true procedures and recursion. Though, I have not tried them so I do not have a say there. fortran 95 supports recursion. this does not imply that the *language* requires a stack. it could be done via heap allocation. i don't know enough fortran to comment intelligently on how its done. Automatic/scoped variables are allocated on the stack frame for procedure calls and/or nested code blocks (Flat Assembler's rendition of the IA-32 enter instruction supports up to 32 stack frames). And without them, programming would be a lot harder. some languages -- notibly c -- assume a stack frame. there are many languages, like fortran that do not. you wouldn't notice what the compiler is doing in those languages. There is also the growing heap for implementing dynamic variables which is quite as problematic as the stack because it, too, can grow beyond bounds and give one headaches. this is an entirely different problem as heap allocations in most languages are *explicit* thus allowing the programmer to respond to the situation appropriately. iirc, v7 sort used a binary search algorithm to figure out how much memory it could sbrk(). e.g. int memsize; for(memsize = 1024*1024; memsize = 4*1024;) if(sbrk(memsize)0) break; - erik
Re: [9fans] /net panic
On Fri, Feb 15, 2008 at 1:19 PM, Iruata Souza [EMAIL PROTECTED] wrote: On Fri, Feb 15, 2008 at 7:20 AM, sqweek [EMAIL PROTECTED] wrote: muzgo (from irc) was playing around with /net in qemu and came across this gem: on drawterm: cpu% cd /net/tcp cpu% cat clone 23cpu% cd 23 cpu% echo connect 10.0.2.1!12345 ctl cpu% cat status Finwait2 qin 0 qout 0 srtt 0 mdev 0 cwin 1461 swin 328500 rwin 655350 timer.start 10 timer.count 10 rerecv 0 katimer.start 200 katimer.count 159 cpu% echo connect 10.0.2.1!12345 ctl cpu% this causes CPU server to reboot with: panic: timerstate1 panic: timerstate1 dumpstack disabled cpu0 exiting The usage of /net is invalid, but you wouldn't really expect that to reboot the machine (or maybe it's a holdover from before /dev/reboot existed? ;) ). Just tried it on my cpu server and got the same panic, so we can rule qemu out. I adjusted the ip!port to something that would accept my connection, and my status was something like Timedwait rather than Finwait2. Second time around I skipped the cat status and still hit the panic so the status read isn't affecting things (which is probably blindingly obvious to anyone familiar with the /net code, but oh well). I appear to be running a realtek 8169 nic: #l0: rtl8169: 100Mbps port 0xE400 irq 11: 000aeb2ff32c Don't know what muzgo was using in qemu, but let me know if I can provide any useful information. -sqweek no *strange* things running, i guess. iru some info about my environment is in http://iru.oitobits.net/9netpanic/ where: QEMU_Plan9 - sh script to run emulated Plan 9 cpuemu_config.tgz - CPU server's /cfg/cpuemu qemu-ifup - sh script to up host-guest tun interfaces, Plan 9 gets tun0 ifconfig.tun0 - tun interface configuration listen.c - listener running on host panic - complete scenario of snap pasted by sqweek iru
Re: [9fans] Google search of the day
On Fri, 15 Feb 2008 14:56:57 -, Brantley Coile [EMAIL PROTECTED] wrote: FORTRAN never had this problem. Its memory needs were fixed at compile time. Neither did COBOL. But then again, you couldn't write recursive programs either; all locals were static storage class. The trade off to get recursion has been worth it anddoesn't cause problems actual use. My understanding has always been that the stack is a fundamental element of the x86 architecture. SP and BP registers, later ESP and EBP, are all about the stack. All return addresses are stored on the stack. Parameter passing relies on it. And I know of no other means of implementing them. Except by avoiding call/ret instructions and solely jmp'ing around in a true mess of a code. No true procedures. I am almost sure the modern incarnations of FORTRAN (90, or even 77?) do support both true procedures and recursion. Though, I have not tried them so I do not have a say there. Automatic/scoped variables are allocated on the stack frame for procedure calls and/or nested code blocks (Flat Assembler's rendition of the IA-32 enter instruction supports up to 32 stack frames). And without them, programming would be a lot harder. There is also the growing heap for implementing dynamic variables which is quite as problematic as the stack because it, too, can grow beyond bounds and give one headaches. It wasn't a problem with Algol, PL/1, Pascal, and C programs onvery small machines. Why should it be a problem with today'smemory sizes? I remember getting a lot of out of stack errors from QuickBASIC, Turbo C and Borland C on MS-DOS. That was back when my computer had 8 MBs of RAM (a Win32 PE today has a default stack size of 8 MBs!) These days, stack overflows are most likely to cause problems by mingling data (return addresses and/or parameters) with executable code. I suppose segmentation mechanisms are there to precisely solve that problem. Never curse the segfault again ;-) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [9fans] ATAPI document
did you get one? i probably have one somewhere online i definitely have old paper copies. --jim On Thu Feb 14 15:17:04 EST 2008, [EMAIL PROTECTED] wrote: Once, long ago, I found a copy of the ATAPI spec that did not require me sending $$$ to T13. Anybody seen that lately or have a link? ron
Re: [9fans] ATAPI document
Bugger. That was meant as private mail. I didn't maean to 'do a boyd'. On Fri Feb 15 11:26:25 EST 2008, [EMAIL PROTECTED] wrote: did you get one? i probably have one somewhere online i definitely have old paper copies. --jim On Thu Feb 14 15:17:04 EST 2008, [EMAIL PROTECTED] wrote: Once, long ago, I found a copy of the ATAPI spec that did not require me sending $$$ to T13. Anybody seen that lately or have a link? ron
Re: [9fans] Google search of the day
http://en.wikipedia.org/wiki/Stackless_Python Is it the same sort of stack ? It mentions Limbo as an inspiration The threaded / concatanative langauges such as Forth / Joy / Cat / V don't use a call stack, though they still use a stack for parameter manipulation. Charles Moore said that you get about 40 items on the stack in a big program iirc, though that was a few years ago. Still, not much use to C based environments. I'm hoping to get good enough at Forth to take one of these puppies for a walk one day : http://www.intellasys.net/index.php?option=com_contenttask=viewid=35Itemid=63
[9fans] ld.com
According to the manual, ld.com is a stripped down version of 9load, intended to fit in 64KB. It doesn't, my production version is: --rwxrwxr-x M 9 sys sys 73464 Feb 18 2007 /386/ld.com which seems to be the current version. Any suggestions? I don't really want to rebuild it unnecessarily. ++L
Re: [9fans] /net panic
On Fri, Feb 15, 2008 at 2:23 PM, erik quanstrom [EMAIL PROTECTED] wrote:
i'm not sure this is a perfect solution. i just don't have enough
of the plan 9 ip stack loaded into cache to be sure nothing's
been forgotten. but give this patch a whirl. basically, i think
the problem is that inittcpctl() was stepping on timers that might
have been active. these timers need to be shutdown. unfortunately,
tcpclose() and localclose() are too agressive. cleanupconnection()
is a chopped-down version of localclose.
- erik
/n/sources/plan9//sys/src/9/ip/tcp.c:782,787 - tcp.c:782,813
return mtu;
}
+ static void
+ cleanupconnection(Conv *s)
+ {
+ Tcpctl *tcb;
+ Reseq *rp,*rp1;
+ Tcppriv *tpriv;
+
+ tpriv = s-p-priv;
+ tcb = (Tcpctl*)s-ptcl;
+
+ iphtrem(tpriv-ht, s);
+
+ tcphalt(tpriv, tcb-timer);
+ tcphalt(tpriv, tcb-rtt_timer);
+ tcphalt(tpriv, tcb-acktimer);
+ tcphalt(tpriv, tcb-katimer);
+
+ /* Flush reassembly queue; nothing more can arrive */
+ for(rp = tcb-reseq; rp != nil; rp = rp1) {
+ rp1 = rp-next;
+ freeblist(rp-bp);
+ free(rp);
+ }
+ tcb-reseq = nil;
+ }
+
void
inittcpctl(Conv *s, int mode)
{
/n/sources/plan9//sys/src/9/ip/tcp.c:792,798 - tcp.c:818,827
tcb = (Tcpctl*)s-ptcl;
- memset(tcb, 0, sizeof(Tcpctl));
+ if(tcb-timer.arg) // c-state != Idle?
+ cleanupconnection(s);
+ else
+ memset(tcb, 0, sizeof(Tcpctl));
tcb-ssthresh = 65535;
tcb-srtt = tcp_irttLOGAGAIN;
works for me.
I don't know the internal workings of the plan 9 ip stack so I take
the risk of being silly: could be that the bug is not tcp only?
iru
Re: [9fans] Google search of the day
#include u.h
#include libc.h
int main() {
for (;;)
fork();
}
Look ma!
John
this is the closest solution i've found:
Patient: Doctor, it hurts when I do this.
Doctor: Then don't do that!
Re: [9fans] ld.com
On Fri, 15 Feb 2008 14:33:09 -, [EMAIL PROTECTED] wrote: According to the manual, ld.com is a stripped down version of 9load, intended to fit in 64KB. It doesn't, my production version is: --rwxrwxr-x M 9 sys sys 73464 Feb 18 2007 /386/ld.com which seems to be the current version. Any suggestions? I don't really want to rebuild it unnecessarily. ++L The one on Plan 9 ISO image is exactly 73,464 bytes, like yours. Strange thing, because MS-DOS COM executables are exact memory dumps (no loader/header/relocation) designed for 16 bit systems which had a segmented memory model (segmented in the ancient sense of the word). They must fit into one 16-bit segment; exactly 64K. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [9fans] /net panic
works for me. I don't know the internal workings of the plan 9 ip stack so I take the risk of being silly: could be that the bug is not tcp only? iru no. the problem is that active tcp timers are overwritten. all the tcp timer code is contained within ip/tcp.c - erik
Re: [9fans] Google search of the day
he musta never done breakpoint in SunOS on a read ... I assume he meant while running Forth
Re: [9fans] Consindering eBox-4854 for Plan9
On Fri, Feb 15, 2008 at 4:38 AM, erik quanstrom [EMAIL PROTECTED] wrote: vesa mode works. unichrome II is propritary and you can't get the programming docs without an nda. That's changing. Native linuxbios mode support is coming. So the information will exist outside NDA. ron
Re: [9fans] Consindering eBox-4854 for Plan9
On Fri, Feb 15, 2008 at 10:47 AM, erik quanstrom [EMAIL PROTECTED] wrote: actually programming documentation or just code? just code, but, while I realize code alone is often useless, I am willing to bet the docs in this case are less useful than code. The code will have all the huge doc gaps filled in. ron
Re: [9fans] Google search of the day
On Fri, Feb 15, 2008 at 8:43 AM, maht [EMAIL PROTECTED] wrote: Charles Moore said that you get about 40 items on the stack in a big program iirc, though that was a few years ago. he musta never done breakpoint in SunOS on a read ... there was so much on the stack you couldn't display it on the screen. ron
Re: [9fans] Consindering eBox-4854 for Plan9
vesa mode works. unichrome II is propritary and you can't get the programming docs without an nda. That's changing. Native linuxbios mode support is coming. So the information will exist outside NDA. ron actually programming documentation or just code? - erik
Re: [9fans] Google search of the day
On Fri, Feb 15, 2008 at 3:35 PM, ron minnich [EMAIL PROTECTED] wrote: On Fri, Feb 15, 2008 at 8:43 AM, maht [EMAIL PROTECTED] wrote: Charles Moore said that you get about 40 items on the stack in a big program iirc, though that was a few years ago. he musta never done breakpoint in SunOS on a read ... there was so much on the stack you couldn't display it on the screen. ron that number^2 for some OS X stuff iru
Re: [9fans] Consindering eBox-4854 for Plan9
I am considering purchasing an eBox IV Series box for a Plan9 installation, and I was curious of any of your successes or failures with these or similar systems. As has been mentioned on the list recently, the Everex gPC sold by Walmart (http://www.walmart.com/catalog/product.do?product_id=7754614) is comparable inasmuch as it's also a Via based system. I ordered one and installed Plan 9 on it without any problems a couple of days ago. (Well I'm getting heavy I/O load after booting even w/ DMA turned on but I suspect that's because I did a fossil+venti install and haven't gotten around to figuring out what's going on.) Video and and ethernet work out of the box. The gPC's case is much bigger than it needs to be so isn't nearly as compact as the eBox, but on the plus side it has more room for expansion. John
Re: [9fans] Consindering eBox-4854 for Plan9
Maybe all the 9fans moved here? http://www.imdb.com/title/tt0418737/ In any event, you forgot: what order of infinity is the work vs. your free time anyway? You might just be slacking. Enquiring minds want to know! the work items are not hard, there are just countablly many of them. since one works at a basically fixed rate, time to complete the countablly many items is countable. ... oh, wait ... sorry. what i mean is hell ya, i'm totally slacking. i haven't finished a driver in *days*. - erik
Re: [9fans] Consindering eBox-4854 for Plan9
actually programming documentation or just code? just code, but, while I realize code alone is often useless, I am willing to bet the docs in this case are less useful than code. The code will have all the huge doc gaps filled in. ☺. it seems to be a truism among hardware folks. the worse the documentation is, the more tightly it is kept. the via parts do a very good job with vesa. i find our 800mhz terminals very usable. the graphics are pretty snappy. i think it would be more of a priority to tackle the amd(ati) and intel parts for which there is actual documentation. intel documentation is not that great, but, you can learn to live with it. fortunately adding one more thing to the list of things to do will not decrease the amount of my infinite spare time. - erik
Re: [9fans] Google search of the day
I think the stack direction is just for the pseudocode, the stack in my implementation grew down, it depends on what assembler primitives are available I guess moddiv: colon divmod swop semi I am genuinely lost, do not understand a word of it. colon tells the inner loop that this is a set of other Words (addresses) not machine instructions so the loop will execute divmod (which does division with modulous and leave the divsor, mod on the stack) swop then reverses the order of the top two stack items semi then jumps to semi to pop the next I before jumping to it It gives you an interactive compiler without linking as you can add new Words at runtime :square dup * would put square : colon dup multiply semi somewhere in memory (called the dictionary) My version uses two stacks, one for args and one for addresses for more analysis I suggest some online reading, I'm not deep enough into either paradigm to offer suitable insights
Re: [9fans] Google search of the day
Let's get back to humor. Here's from ReactOS 0.3.4's shutdown screen: The End . Try the sequel, hit the reset button right now! You can switch off your computer now
Re: [9fans] Consindering eBox-4854 for Plan9
As has been mentioned on the list recently, the Everex gPC sold by Walmart (http://www.walmart.com/catalog/product.do?product_id=7754614) Double-checking the link it looks like I got mine just in time as that page now says that it's no longer sold online. Don't know if that means they're simply sold out or want you to pay extra for the Vista version. John
Re: [9fans] Consindering eBox-4854 for Plan9
On Fri, Feb 15, 2008 at 10:56 AM, erik quanstrom [EMAIL PROTECTED] wrote: fortunately adding one more thing to the list of things to do will not decrease the amount of my infinite spare time. Maybe all the 9fans moved here? http://www.imdb.com/title/tt0418737/ In any event, you forgot: what order of infinity is the work vs. your free time anyway? You might just be slacking. Enquiring minds want to know! ron
Re: [9fans] Google search of the day
On Fri, 15 Feb 2008 19:05:28 -, maht [EMAIL PROTECTED] wrote: Forth doesn't use CALL it uses JMP Similar Threaded Interpretive Languages run an inner loop that does this pseudo code : (from Threaded Interpretive Languages: Their Design and Implementation by R. G. Loeliger) COLON: PSH I - RS WA - I JMP NEXT SEMI: POP RS - I NEXT: @I - WA I += 2 RUN: @WA - CA WA += 2 CA - PC I know nothing about interpreted/interpretive languages but the above pseudo-code is, to my own surprise, quite readable to me. The indirection pointer seems to funcionally match the (stack) base pointer on x86, with the word address equalling the stack pointer. So, the above says: - Save the stack base address (PSH is PUSH, I assume). - Set the stack base address to the beginning of the current frame. - Jump to NEXT. - Put the return address on top of the stack. - Reserve space on the stack for one 16-bit (2-byte) address by incerementing the base pointer. On x86 one would decrement the base because the stack grows from higher addresses towards 0x0. - Set the the call address to the beginning of the procedure. - Set the program counter to the procedure (call it, in other words). One strange thing is that code and (stack) data seem to both grow from 0x0 towards 0x unlike x86 where the code sits in low address and the stack grows downwards. You have re-implemented the calling mechanism. You still have a call stack and the pertaining problems, but you have lost the convenience of a simple call instruction. By the way, now I see what Erik Quanstrom meant by alternative calling conventions. Your pseudo-code is an example. that's all very well but you then extend the assembler parts with new words made from the WAs (colon is the type marker for this) SEMI is where it JMPs to at the end moddiv: colon divmod swop semi I am genuinely lost, do not understand a word of it. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [9fans] Non-stack-based calling conventions
- DOS interrupt function calls use the registers, not the stack. - SPARC and MIPS registers are provided to pass parameters. On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: The calling conventions I have seen are the ccall, stdcall (Windows' slightly modified version of the ccall), and pascal. All of them push parameters on the stack. Take a look at the R-call and S-call conventions used on the IBM System 360 architecture. These machines didn't even have a stack. --lyndon
[9fans] Non-stack-based calling conventions
The calling conventions I have seen are the ccall, stdcall (Windows' slightly modified version of the ccall), and pascal. All of them push parameters on the stack. Take a look at the R-call and S-call conventions used on the IBM System 360 architecture. These machines didn't even have a stack. --lyndon
Re: [9fans] Non-stack-based calling conventions
I don't have latest version of fascicle one (MMIX processor architecture and MMIXAL assembler language, from new version of The Art of Computer Programming) at hand, so I can't confirm it, but I remember that MMIX had a special register which implemented a border, shifting register numbers to use them for procedure data separation. And as in all RISC architectures, storing as many parameters in the call stack is the way to go. Especially when you have 256 64-bit general purpose registers :-) (Now if only someone implemented a sane architecture using MMIX as main processor...) On 2/16/08, Pietro Gagliardi [EMAIL PROTECTED] wrote: - DOS interrupt function calls use the registers, not the stack. - SPARC and MIPS registers are provided to pass parameters. On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: The calling conventions I have seen are the ccall, stdcall (Windows' slightly modified version of the ccall), and pascal. All of them push parameters on the stack. Take a look at the R-call and S-call conventions used on the IBM System 360 architecture. These machines didn't even have a stack. --lyndon -- Paul Lasek
Re: [9fans] Non-stack-based calling conventions
Early Control Data machines, like many machines of the era, used the return address to fine the parameters. This meant that you put he parameters in the instruction stream right after the call to the subroutine. Here's the calling convention for your entertainment. 1) The calling program would put the parameters into memory locations just past the call to the subroutine. 2) Do a return-jump to the subroutine. This puts the return address in the first word of the subroutine and begins to execute the second word. 3) Parameters are accessed by using and incrementing the return address. 4) With the return address now safely stored in the first word of the subroutine, we can now return to the calling routine just by doing a indirect jump thru the first word of the routine. All this might not make sense to you so here is some code. This is CDC 1830 assembler, the best I can remember it. CDC 6600 works the same, but the code would be more confusing to the unfamiliar. . . * call sub(p1, p2) ena parm1 put the parameter into the A register sta p1save it in the instruction stream right after the rtj ena parm2 we have two parameters. sta p2 rtj sub save RA at sub, begin executing at sub+1 p1bss 1 p2bss 1 jmp error * first address to return to . . . sub bss 1 place to keep the return address ldq sub lda (q) inq 1 point to next parameter lda (q) inq 2 point to last parameter and no error stq sub put parameter back jmp (sub) jmp indirect thru sub--return By convention there we would follow the parameters with a jump to an error handler and have the subroutine increment the RA another time in case the subroutine had no error. The IBM 7094 did a similar trick only it put the return address, or I should say the 2's complement of it, in an index register before it jumped to the subroutine. Parameters were picked up using the index register. (7094 indexes seem strange to us now, but they were *subtracted* from the base address in the instruction.) The subroutine used a form of the transfer instruction that added the number of words to the return address, er, I mean subtracted, to return to the caller. All the memory you would need was known as compile time. Writing assembler meant watching for trying to execute parameters as instructions. This does wonders for the design of the instruction cache. :)
[9fans] s3
glad i'm not depending on it: http://www.news.com/8301-10784_3-9873068-7.html?tag=nefd.top - erik
