Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33726
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Metrics on stack usage |
| Date | 2014-10-07 04:49 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <m109fo$2f1$1@dont-email.me> (permalink) |
| References | (14 earlier) <m0q05g$hn9$1@online.de> <m0s7cl$ve6$1@dont-email.me> <m0ss5f$r0s$1@online.de> <m0t4sa$nj4$1@dont-email.me> <m0ul6o$76u$1@online.de> |
On 10/6/2014 1:57 PM, Bernd Paysan wrote: > 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". Actually you quoted me saying "skill levels" just above, but whatever. The point is their work methods will grow and change. Is that better terminology? >> 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 think you are drifting now. We were talking about type checking. I'm not sure how this ties in. >> 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. Ok, then I freely acknowledge I don't know what is in your mind. Care to explain it in terms someone else can understand? >> 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). Ok, what is the relevance? You tend to throw stuff out there without explaining how it ties into the discussion. >>>>> 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. Wow, I figured you would have something substantial. If this is your evidence I think it is a bit thin. I remember when this was done. I think the report you link to was a second try or maybe a third. The first try had organizational issues and I seem to recall that no one finished. Even in this trial the winning entry didn't pass the criteria. Your statement was that "Verilog is about 3 times as productive as VHDL". The evidence to say this is not true is that were it true, no one would still be using VHDL, even the US government (who often requires it on government contracts) would walk away from it. >>> 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. No, I am saying there are right ways to write VHDL and wrong ways to write it. I made similar mistakes when I was a newbie. So I have first hand knowledge that it is a newbie mistake. I think anyone who cares to look at it objectively would understand that there were two mistakes made. The first was the coding error... the second was writing 5000 lines of code before touching the compile button... an even worse newbie mistake. Can you really claim that anyone who makes the second error isn't a newbie? > This was someone who taught VHDL to other people at Siemens HL. I feel sorry for Siemens... Ok, the guy isn't a newbie, he is just not very good at VHDL... > 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. Ok... >> 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. He never got the counters to wrap around in his simulation??? I think it is very clear this is all cockpit error. >> 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. Ok, if you say so... >> Of course no one ever has any problems learning Forth... lol > > Again: He wasn't a clueless newbie at all. No, he was just clueless.. That is obvious to anyone at all proficient in VHDL. Was this a long time ago, like the Cooley competition? >> 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. No, you didn't make the decision, but you are judging the language on what he decided and you don't know enough about the language to know the problem was all user issues, not the language in any way. I am pretty sure I learned about the wrap around thing the first time I used integers. It didn't take me 5000 lines of code to figure it out either because I simulate each of my modules in much the same way you test your forth words. >> 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. Ok, but that is your preference, not a problem with the tools. I am very proficient with VHDL when I am working with it. I don't think I would be any less proficient with Verilog if I used it much, but it has "gotchas" that I have not learned so I shy away... so far. I also like some of the features in VHDL which are useful in test benches. > 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. "HDL Chip Design" by Douglas J. Smith by any chance? I have that book. I haven't used it extensively though. >> 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"... Boilerplate is just that, boilerplate and doesn't take much time to deal with. I have editor macros that help me turn architecture port lists into signal declarations as well as port mappings (or back). Making changes is not as much fun, but port lists are a pita in any language... hence the stack in Forth, no? Yes, I'll acknowledge that VHDL is more verbose than Verilog, but it isn't even close to cutting productivity to a third. >> 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. Maybe HDL and Forth is not a good comparison. I don't see manual entry as a way to test code well. Each test needs to be given enough thought that it tests the entire set of requirements. It needs to be documented so that someone following in the footsteps can understand what was being done (usually me in my case, but I don't remember what code did after two or three years). So I write my tests the same way I write my code. Sure it takes longer, but I need something I can return to later and understand. >> 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. Please reread the paragraph I wrote. I said I write test benches the *same* way you might test Forth code... not differently. > 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. I don't follow. Every time you find someone who is not good at their job, you blame it on the tools they use. >> 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 ;-). I don't understand. When I write code, I test in small increments. Why is this being coded in large blocks before being compiled or tested? >> 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". What does that have to do with Verilog and VHDL??? > 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. I'd love to see references. >> 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. I don't even know what that means. >> 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. I'm not sure which VHDL "bigot" you are talking about, but again, the guy was a poor designer... that doesn't mean the tools were bad. > 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. Maybe that is what people who don't know what they are doing do... but that isn't the language. You can get yourself into trouble very quickly with Verilog or Forth if you don't know what you are doing. I will admit that VHDL is not as simple as I would like it. But it is not so hard to learn. I was confused early on by having bad teachers, likely similar to the guy you are talking about as being an "expert". But with time and experience I discovered realities and can code pretty well now. I even taught someone else to code in VHDL. > 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 don't know what you are talking about now. I don't use bit vectors for anything. These days I usually use signed, unsigned, integers or sometimes Boolean. Once in awhile I use enumerated. I don't have any trouble concatenating values and using them for assignments or comparisons. You may have seen problems with string literals in older versions of VHDL. Back in VHDL-1987 there was a problem where the compiler couldn't tell if you meant the string literal to be this type or that type and you had to cast it. But that has been fixed for what, two decades (VHDL-1993)? > 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. Ok. -- Rick
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