Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33719
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Metrics on stack usage |
| Date | 2014-10-06 19:57 +0200 |
| Organization | 1&1 Internet AG |
| Message-ID | <m0ul6o$76u$1@online.de> (permalink) |
| References | (13 earlier) <m0cvou$hh8$1@dont-email.me> <m0q05g$hn9$1@online.de> <m0s7cl$ve6$1@dont-email.me> <m0ss5f$r0s$1@online.de> <m0t4sa$nj4$1@dont-email.me> |
rickman wrote: >>> I don't know that I would use the opinions of students as a good metric. >>> Their skill levels are fairly low compared to professional >>> programmers. I expect their tastes will change as their skill levels >>> change. >> >> I don't think so. Preferrences are set pretty early in education. > > We aren't talking about "preferences", You said "taste". That's a "preference", not a "skill set". > we are talking about skill sets. > I know my techniques of design and debug have changed several times > over my career. The problem is: if the mainstream doesn't have that option (of a Forth-like environment), they will probably never see it. > I am familiar with the Doherty threshold... lol The compile step is a > natural change of pace in thinking, so the same issue you have in a GUI > doesn't apply to the same extent. When changing from editing to > compile/test the mode of thinking is different so a delay of a small > number of seconds is much more readily accepted without impact on > performance. I don't see it as that. The compile step always gets into my way of thinking. If you see coding and testing as something separate, you already have a mindset that doesn't allow you to get into the "flow" Forth programmer experience. Therefore, you don't know what I'm talking about. > There are several thresholds for this. The exact values are quoted > differently, but anything less than about 0.3 seconds is normally not > perceived as a delay. A delay less than about 3 seconds is tolerated > without loosing focus, above 30 seconds is a significant disruption to > workflow and often means the user leaves the task for another. > > As I said, my experience with both C compilers and VHDL compiles is that > the delays are short enough they don't significantly impact my task > completion time. I can't remember a compile that took anywhere near 30 > seconds and often they are less than the 3 second attention threshold. > Your experience may differ. Compiling Gforth after a make clean takes 43s on my core i7 here. That's not a particularly large project... and the majority of the source code is Forth. Compiling gforth.fi from the kernel + image sources takes 0.3s (that includes relocating stuff, so actually the image sources are compiled three times in this 0.3s). >>>> And then you figure out that you urgently want some help from the >>>> compiler, >>>> because your programs all don't run. And the typecheck is giving that, >>>> at least it is giving you the illusion of the compiler doing something >>>> - complaining and making you change the program before you run it. >>> >>> I don't know about "illusion". I think the sort of problems I would >>> have in VHDL from mismatched types can often be the sort that you spend >>> significant debug time finding. >> >> Verilog is about 3 times as productive as VHDL for the same problem >> space. > > I have never seen that substantiated... what do you base this on? John Cooley's competition was really funny: http://www.see.ed.ac.uk/~gerard/Teach/Verilog/manual/Example/lrgeEx2/cooley.html That was 90 minutes for a trivial task with 9 Verilog and 5 VHDL participants. 5 fully functional netlists were produced, all of them from Verilog code; the VHDL participats all failed. Two of them acutally complained about being brought down by VHDL's type system: "Two of the VHDL designers, Prasad Paranjpe of LSI Logic and Jan Decaluwe of Easics, both complained of having to deal with type conversions in VHDL. Prasad confessed: "I can't believe I got caught on a simple typing error. I used IEEE std_logic_arith, which requires use of unsigned & signed subtypes, instead of std_logic_unsigned." Jan agreed and added: "I ran into a problem with VHDL or VSS (I'm still not sure.) This case statement doesn't analyze: "subtype two_bits is unsigned(1 downto 0); case two_bits'(up & down)..." But what worked was: "case two_bits'(up, down)..." Finally I solved this problem by assigning the concatenation first to a auxiliary variable."" There were other sources, but I forgot them. This is all early 90s stuff. >> The author of the code went through 5000 lines of code, to >> replace all "+1" of these integers (he had several) with an "when 15 then >> 0 else +1" idiom. > > Sounds to me like a very inexperienced newbie... You are repeating the standard VHDL bigot arguments John Cooley has been collecting: If someone fails in VHDL, it's because he is a clueless newbie. This was someone who taught VHDL to other people at Siemens HL. I'm not at all convinced that his coding style is a good idea, and I think it's a bad idea to teach this coding style to others. But that coding style is found widely in the VHDL world. I've even seen people who later in their career moved to Verilog keeping that coding style. Like you can write Fortran programs in any language, you can write VHDL programs in any HDL. > Why would anyone write > 5000 lines of code before doing any simulation or even a test compile? He did. The 5000 lines compiled, and synthesized (with a warning of 500 latches created from asynchronous processes... doh!). All those corner cases in which the VHDL simulator throw an exception were found by the test code I had written. > How is that a problem with the language? Your assumptions about the reasons were all wrong, so the conclusion that it isn't a problem of the language therefore is very likely to be wrong, too. > Of course no one ever has any problems learning Forth... lol Again: He wasn't a clueless newbie at all. > Sounds like you are not at all familiar with VHDL. If you want a modulo > 16 value you can use a 4 bit unsigned signal. This is easily converted > to an integer when you use it to index an array. I believe the form for > that is to_integer(). Not so hard - is it? It's not about me, I didn't make that design choice of using an integer subtype. The actual problem you refuse to acknowledge is that in a HDL you want an integer mod 2^n type, because that's what you use to build your logic of. Verilog gives you that (it is the only synthesizable type it has), VHDL denies you that. > You have your preferences based on your experiences. I believe you > would have had a similar experience if you didn't know Forth and started > working at a company that used Forth, but didn't really get it and > misused it extensively. The problem is that it was the professionals who ought to know who misused it extensively. The teaching material of HDL on my university was all VHDL, and the TU Munich is one of the best universities in Germany, especially on these electro engineering topics. I chose Verilog, because I looked at teaching material on the internet, and the Verilog stuff all makes way more sense. I then switched an entire small company from VHDL to Verilog in a few months, and all these VHDL coders liked Verilog. They weren't forced to, they were convinced. And not by my arguments, we had bought a "Verilog VHDL side by side" book to make the transition. > What is the incentive to write "big" modules in VHDL? I don't typically > write large ones. The incentive that it is more boilerplate: You need architecture, implementation and instantiation, which all takes way more to type in, especially for small modules, where the implicit port passing of Verilog is acceptable. Maybe we also disagree on what is "large" or "small"... > The only "incentive" I find is that I test all my > modules with a test bench, so I have to construct that framework. I > suppose in Forth you would manually type in the tests, but that wouldn't > fly in a production environment where you need to document your testing, > so each word needs a word to test it... thoroughly. You manually type in the tests while you develop the word. And if you then want to have a regression test, you cut&paste the tests out of the history file - or the command line, because there, you have the result, too. And then wrap them up in a facility like ttester.fs - this is not a word which tests another word. > I mean I write the test bench the same way you would write your test > code in Forth, it reports a pass/fail, not a number for the user to > interpret if that was a valid response. In an HDL you need to consider > values of signals at various times. This is very hard to do without a > good test bench or a lot of manual examination of detailed waveforms. > Not very much like software really. There's something I don't understand about many hardware designer, and that is this "not very much like software" stuff. My stuff usually is pretty small, and involves a microcontroller or similar microcode sequencer. This stuff is behaving like software, it is pretty fast to develop, it is robust and small, easy to get bug-free, doesn't consume much space on the chip, etc. And it just works a lot better than the "not like software" big state machines of the hardware engineers. And yes, I've written fancy test benches for these big state machines of the hardware engineers, too - I pretty well know what it takes to make them. You know what happened with the big state machine of this coworker? The other two people in the team, me and another VHDL guy, got fed up with debugging this hopeless stuff, and I designed a small CPU, which my coworker implemented. This did the same job in much less gate space, but the higher up bosses shelfed that approach, because our rescue came too late: The entire project had been so much out of budget that it was completely shelfed. I then left Siemens HL (I was just a consultant, and hired for that particular project), I think our approach was rescued a few months later. > But if you are testing your code in small pieces it will be pretty > obvious where the problem is. If the tool is checking stack effects at > compile time, it surely can tell you which work has the problem. > Otherwise what is it checking? It is checking the whole definition, all words together. One of these words doesn't have the stack effect I'm thinking it should have, and that's what causes the problem. However, the compiler can't know what I'm thinking, therefore, it can't tell me which particular word causes the problem. That's not a problem if your definition is just using one single word. But that's the silly cornercase ;-). > You make claims about Verilog, but I would like to see some evidence > that isn't anecdotal. That was one of my problems trying to justify > Forth in the workplace. There isn't any real info on it's advantages, > it is all anecdotal. I don't think that e.g. the stuff Paul Benett does qualifies as "anecdotal" - he has all his certificates to proof that his high reliability stuff really is high reliable. I think people just like to dismiss reports that don't fit into their believe system as "anecdotal". I've recently watched a presentation about getting towards scientific analysis of software engineering, i.e. providing solid studies instead of all the anecdotal evidence we have, and the conclusion was that solid studies cost an awful lot (it's just like a phamaceutical trial study). But the results of these few solid studies we actually have, all back up methods we have used in Forth for 40 years. Dismissing them, even though several of these methods are now backed up by solid studies is silly. > Actually, there are a number of times the lack of type checking will get > you into trouble in Verilog. The system makes assumptions about what > you are trying to do and you need to be *completely* aware of those > assumptions in all cases or it doesn't work right. Yes, that is true. That is true for every programming language - you always have to be completely aware of everything. The assumptions Verilog makes are very straight-forward and simple, which is why it doesn't take long to learn - the "everything" space is much less than with VHDL's contrived type system, which gives you almost everything, except the thing you actually need. > So Verilog also has > a learning curve. The difference is the VHDL issues slow you down until > you learn to deal with them. Verilog issues create faulty code until > you learn to deal with them. Verilog doesn't "just work". You need to be completely aware that all bit vectors in Verilog are mod 2^n numbers, that bits and bit vectors can be assigned to each other, concatenated together forming another bit vector, and you can select parts of bit vectors, creating new bits or bit vectors (depending on the selection style). That's all. That's a natural fit to what you want in a HDL. VHDL's type system doesn't fit, and therefore, it always gets into your way, newbie or expert. And the resulting code doesn't work, even though the VHDL bigot always tells you that the compiler catches all bugs. That's, because the VHDL bigot took a week to get his code to compile, and then is too exhausted to run extensive tests. I did run these tests, and they found tons of bugs, in the code declared bug-free by the VHDL bigot, because he finally managed to compile it (because it took so long to make it compile! Proof by effort!). It wasn't. The "when 15 then 0 else +1" wasn't the only type system cockup this code had. Your assumption is when you make an explicit typecast, you are aware of what you are doing. With a type system with std_logic, std_ulogic, int, subsets of int, tuples, and whatnot, you can't get your head around all this mess. You don't know what you are doing. You are inserting typecasts to make the damn'd thing compile. In Verilog, when you concat two bit vectors, the result is not a tuple, which is type-incompatible to everything else, it's just another bit vector. It just works - the default behavior fits the assumption you make about how it should work. In VHDL, it just doesn't work. And it's not just me who can't get his head around VHDL. I know that a lot of people can only think complex, and can't find simple solutions. Maybe they also don't *want* to have a simple solution. But nonetheless, the complexity they create doesn't work. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 11:22 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 11:41 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:20 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 13:39 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:11 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 17:24 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:58 -0400
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 08:47 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 14:41 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-16 18:55 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 14:33 -1000
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 18:30 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-16 15:44 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:22 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 09:18 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:39 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:41 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 16:11 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 16:34 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-17 17:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 07:21 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 10:01 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 07:42 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 14:46 +0000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 08:09 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 03:41 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:31 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 14:53 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 16:44 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 15:52 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-30 00:08 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 04:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:48 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 12:26 -0500
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 17:07 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-17 07:20 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:03 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:40 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 09:56 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:54 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 15:13 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 13:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 11:13 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 21:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 16:57 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-23 00:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 19:53 -1000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 03:48 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-23 16:01 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 08:07 -1000
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-09-23 22:11 +0100
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 16:22 -0500
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 11:28 -1000
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-24 11:56 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:52 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:00 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:04 -0400
Re: Metrics on stack usage Michael Barry <barrym95838@yahoo.com> - 2014-09-24 16:08 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 12:23 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 19:33 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:02 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-25 18:48 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 16:58 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-24 16:02 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 19:14 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 10:15 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 13:54 -1000
Typing, was [Re: Metrics on stack usage] "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-24 21:07 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 15:25 -1000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-24 18:43 -0700
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 16:08 -1000
Re: Typing, was [Re: Metrics on stack usage] Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:11 -0700
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-10-01 09:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:38 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-29 17:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-30 09:13 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-30 22:37 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-03 16:10 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 08:42 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 14:59 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 09:07 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 17:28 -0400
Re: Typing, was [Re: Metrics on stack usage] Howerd <howerdo@yahoo.co.uk> - 2014-10-04 11:15 -0700
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-07 23:37 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-07 15:07 -1000
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-12 03:03 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-12 10:42 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-13 00:26 +0200
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-11 19:30 -1000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-08 03:42 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 02:46 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 00:43 +0200
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 18:45 +0000
Re: Typing, was [Re: Metrics on stack usage] "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-25 09:22 +0200
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 17:09 +0000
Re: Metrics on stack usage Kaz Kylheku <kaz@kylheku.com> - 2014-09-25 01:43 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:15 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:19 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:06 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 04:25 -0400
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 03:15 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 14:43 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 22:23 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:42 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 14:23 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 10:14 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 17:10 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 12:31 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 21:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 01:34 +0200
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-05 03:29 -0500
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-05 13:46 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-05 15:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 03:44 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 00:12 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-05 18:56 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 01:34 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 19:57 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-07 04:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 16:21 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 05:43 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 02:35 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 21:48 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 05:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 01:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 21:27 +0200
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 00:01 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 19:59 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 03:33 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:30 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-11 15:22 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-11 22:24 -0400
Loading libraries (was: Metrics on stack usage) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-11 09:23 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:11 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:36 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:38 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 23:39 -0400
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-11 12:25 +0100
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 07:52 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 00:34 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-01 23:26 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-01 16:15 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-01 21:57 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 01:20 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-02 15:59 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 19:29 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-03 15:03 +0000
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 02:27 +0200
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-05 09:22 +0100
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-23 19:36 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:40 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-16 17:06 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 07:43 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:04 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:34 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:30 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-17 12:42 -1000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:33 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-18 11:53 -1000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-19 01:14 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 03:32 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:41 +0000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 12:14 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:41 +0000
Re: Metrics on stack usage mhx@iae.nl - 2014-09-19 12:31 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 12:59 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:05 +0000
Re: Metrics on stack usage Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-09-21 07:44 +0200
Re: Metrics on stack usage Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-09-17 11:10 +0200
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-17 14:20 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:41 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-17 16:44 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-18 10:26 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-19 00:12 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-18 19:15 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-18 17:14 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:59 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-19 12:20 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-20 09:04 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 18:08 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-30 04:33 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 19:30 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-30 11:24 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-30 10:55 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-30 18:39 -0700
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-10-01 01:44 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-01 03:57 -0500
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 18:45 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-02 07:53 -0400
Re: Metrics on stack usage G Smith <do.not.use@tectimco.com> - 2014-10-02 13:22 +0100
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-02 08:36 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-02 15:34 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:08 +0000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 18:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-19 13:28 -1000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 19:57 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 13:09 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-20 13:27 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 08:04 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 08:55 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:01 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:15 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 06:57 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 07:31 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:04 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:17 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:49 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:57 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 19:47 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 02:58 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:28 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-21 11:24 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:55 -0400
Re: Metrics on stack usage Coos Haak <chforth@hccnet.nl> - 2014-09-20 14:57 +0200
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:22 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:25 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:08 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:38 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:19 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:35 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:00 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 08:54 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 03:26 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 10:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:29 -0400
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:53 -0700
csiph-web