Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33802
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Metrics on stack usage |
| Date | 2014-10-10 01:07 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <m17pik$dqa$1@dont-email.me> (permalink) |
| References | (20 earlier) <m10stb$fh9$1@online.de> <m1310n$vum$1@dont-email.me> <m14l8m$fr9$1@online.de> <m14pio$2fq$1@dont-email.me> <m17i9k$fue$1@online.de> |
On 10/9/2014 11:03 PM, Bernd Paysan wrote:
> rickman wrote:
>
>> On 10/8/2014 8:35 PM, Bernd Paysan wrote:
>>> rickman wrote:
>>>
>>>> Ok, so he is an idiot. That explains why his mistakes were not detected
>>>> by the compiler and why he didn't find the error until he had written
>>>> 5000 lines of code. What does this have to do with VHDL or any other
>>>> language?
>>>
>>> Because the entire argument about this typechecking nonsense is that the
>>> compiler will find the errors in the program.
>>
>> Yes, it will find type errors.
>
> The actual question is if that is useful or not. You dodge this question.
I think I have been clear on this. Type error checking can find errors
that can otherwise go undetected in unit test and require more extensive
debugging in system test. Even if they are uncovered in unit test, it
is still more productive to find them at compile time.
The problem is you keep bringing in irrelevant examples of
inefficiencies that have *nothing* to do with type checking but rather
are crappy coders making stupid mistakes.
>>> Fact is: It won't even find
>>> silly errors, but introduce *more* errors.
>>
>> Hmmm... ok if you say so. Most of your arguments on this topic are
>> statements without substantiation. You seem to be convinced of their
>> accuracy regardless. I doubt there is much anyone can say to change
>> your mind.
>
> Or *your* mind. I gave an example: You want a 4 bit index into an array
> (register file). In Verilog, it's easy:
>
> reg [3:0] index;
>
> This is pretty much the only way you can do this 4 bit index stuff, but it
> works: it does wrap around, it can index the array, and it has 4 bits.
>
> In VHDL, well, an index ought to be an integer, so the idea was to specify a
> 0..15 subset of the integer. Works well, unless you increment it and it
> should wrap around. The wraparound is a corner-case.
>
> Of course, VHDL's type system allows you to define this in many different
> ways, but there's no single way which satisfies all requirements: should
> wrap around, should be 4 bits, and should allow to index an array without
> further typecast.
>
> This sort of "you don't get what you need" inevitable leads to *more* errors
> in the code.
From some actual code I wrote, I only changed the range of the unsigned.
Signal declaration...
signal WriteCntr : unsigned (3 downto 0);
Signal usage...
FIFORam(to_integer(WriteCntr)) <= DataWr;
Yes, that is extremely complex. I can see why Verilog is such a better
language. I guess the idea that VHDL is not the spawn of the devil is
all in my mind.
>>> But the whole point about a typesafe language *is* that it helps to find
>>> all the idiotic mistakes people make, by simply compiling the source.
>>
>> No, I don't recall anyone saying it will catch "all mistakes".
>
> But of course you said it was quite helpful, and that Verilog's inexistent
> type-checking is causing lots of problems, without stating even one example.
> And I gave one example (out of several observations), and it's dismissed.
I don't think I said much if any of that. But I will say now that there
are problems that happen from mismatched data types. Maybe it was in a
different newsgroup, but someone just posted an example where a function
was called to return a value and it was used as if it were an integer
while it was actually a boolean. His lament was that this was not
caught in a code review because he works alone and has no code reviews.
I seem to recall that he also mentioned that it should have been
flagged by the C compiler but wasn't.
> That sort of argument isn't very convincing. Except that it convinces me
> that arguing with you is a waste of time.
But you persist.
>>> And yes, all my other coworkers did struggle with the typechecker of
>>> VHDL, as did I.
>>
>> I'm sure that is a problem easily solved by a bit of education.
>
> So you agree with me that VHDL is difficult to learn. My point is that you
> don't have to learn all the tricks to get around the cliffs of VHDL: Just
> take the few weeks to learn Verilog.
I would agree that VHDL is *harder* to learn than Verilog if I had
actually learned Verilog to the same proficiency as VHDL, but I have
not, partly because I have asked a number of times for recommendations
for *good* Verilog books and I am repeatedly told there are *none* that
qualify as good.
I think I said that I intended to learn Verilog better, but I keep
finding that I have no reason. If I could find one reference text that
covers all the gotchas I'd go for it.
>> I get
>> the impression your use of VHDL was some time ago. If it was before
>> numeric_std was in widespread usage then yes, you would have found the
>> process of type conversion to be harder.
>
> No, we had numeric_std. Of course you always had to remember to add this
> package to the boiler plate, or nothing would work.
Uh, why wasn't it *in* your boilerplate? Don't you copy the boilerplate
from a template or an existing file to the next? Is that *really* a
complaint that you had to add a library reference???
> In Verilog, this sort of stuff simply works out of the box. All these
> little annoyances in VHDL add up, and create the feeling of a very badly
> designed language.
Now you are in troll land. If you can't handle two or three library
references, how do you ever work in Forth? You don't use any libraries?
>> Std_logic_vectors were not
>> supported at all for math. Signed and unsigned types are much easier to
>> use. But with more recent additions to the language even
>> std_logic_vectors are math friendly.
>
> Can you now index an array using std_logic_vectors? AFAIK that's still not
> possible.
My example above does that for unsigned types. I believe that is also
now defined for std_logic_vectors. I'm not really current with the 2008
updates actually. It takes two or three years for the new standards to
find their way into the tools and I haven't done a major project since
then so I've not really used the newer features.
>> Again, this is not a problem with the language, this is a problem with a
>> crappy tool. This must have been a *very* long time ago. I have used
>> VHDL since around 1995 and I have never used tools that required any use
>> of Verilog. Bizarre. What tools were these?
>
> This is far from bizarre. The ASIC vendor we had (AMS and Xfab, back then
> called Thesis) had only Verilog simulation libraries of their cells, and
> that is still quite common. The simulator did offer a VHDL+Verilog
> cosimulation, and it was Modelsim, not something weird. Mikron did make the
> switch from VHDL to Verilog in 1999.
I believe the ASIC community is one where Verilog is dominant, likewise
the telecom suppliers. Much of Europe is VHDL as it the defense
community here in the US. The last I heard the rest of the engineering
world was split. The area around Washington DC is split between defense
and telecom so I have done work with both languages.
Funny, when I worked at a telecom company we were working in Verilog,
but I seem to remember writing test benches in VHDL. Maybe I was
designing them with VHDL then converted them to Verilog. It involved
reading in a custom command file which had to be interpreted to control
the test fixture. I think it was for bus reads and writes to emulate a
processor interface. Is that easy to do in Verilog?
>> You are fond of working with very limited data sets, so here is one to
>> disprove your postulate. I have learned VHDL well and yet have not
>> learned to use Verilog to the point I would prefer to use my code in a
>> product. So 100% of my sample indicates Verilog is harder to learn.
>
> Ok, so you have 1 sample point, which opposes my sample points. I've met
> about 30 engineers which had at one or another point in time switched from
> VHDL to Verilog, and none of them found Verilog difficult to learn.
My point is that your sample set is rather small. So I gave you a
contrary example which is also small. Neither is convincing, eh?
>> As I have mentioned before, Verilog has a set of aspects you need to
>> learn about or you can produce buggy designs without realizing it. I
>> don't recall the details and in fact I have never learned them all. You
>> have acknowledged these aspects exist. Do you have a list written down
>> somewhere? How did you teach your coworkers to use Verilog if you don't
>> have this list? How did they learn about these issues?
>
> We had a "Verilog and VHDL side by side" book, and they read it. Some
> typical thing you need to know:
>
> All assignments in always @(signal list) asynchrnous blocks have to be
> blocking (i.e. with the variable = assignment syntax); in Verilog 2001, you
> have always @*, and you shall use it when Verilog 2001 is an option
> (otherwise, forgetting a signal in the sensitivity list leads to
> inconsistent results between simulation and synthesis).
I have heard about the blocking vs. non-blocking thing, but I can never
remember which is which by name. I seem to recall the idea is to create
the equivalent of signal assignments in VHDL which are not assigned
until the process waits (usually the end for a clocked process). They
both use the same assignment operator <= no?
In VHDL variables are assigned with := which operates immediately just
as assignments in a C program. So <= is non-blocking and = is blocking?
Now that I have my head straight on this, why are blocking assignments
required in async blocks? Does it not synthesize correctly and create a
register or something odd if you use a non-blocking assignment?
> All assignments in always @(posedge/negedge signal list) blocks have to be
> non-blocking (with the variable <= assignment syntax); the synchronous
> blocks shall have one clock and one reset input only.
Yeah, that is the one I remember.
> You can't mix @(signal or posedge signal), i.e. either a block is
> synchronous or asynchronous.
>
> A process with asynchronous nreset (active low) and clock looks like that:
>
> always @(posedge clk or negedge nreset)
> if(!nreset) begin
> <initiatization code>
> end else begin
> <clock triggered code>
> end
>
> Declare all variables in blocks with "reg", declare all variables in
> continuous assignments with "wire". IOs are wires by default, unless
> declared as reg (works only for outputs of course, and is Verilog 2001).
> All variables in an async process must be assigned in all possible cases,
> otherwise they will create a latch (identical rule in VHDL).
>
> Some stuff is "style guide"; these rules apply independent of the language.
> With tools for the last 15 years, having an asynchronous process to do the
> calculations, and a synchronous process only for register updates is no
> longer necessary, so don't split these things up - the two variable names
> clutter the namespace, and cause endless amounts of confusion - use just one
> name, and do all calculation and update synchonous. The synthesis tool is
> perfect at separating variables, too, so no need to manually split processes
> up. You should not have negedge clock tasks, as they break ATPG (if you
> need to sample at negative clock edges, you have to create a separate clock
> signal that is fed from the inverted clock in normal mode, but from the test
> clock in ATPG mode).
>
> Some people who converted from VHDL to Verilog thought that the left and
> right shift operators in Verilog had the same problems as in VHDL, and
> therefore avoided them. They don't, they work fine and are straight-forward
> unsigned shifts.
What's wrong with the shift operators in VHDL? I have to say I don't
use them much as they simply save some typing and I hate having to
remember the details of how they are used. I just do my own shifting
with an aggregate.
> There's no signed data type in Verilog; if you need signed multiplication,
> make sure you deal with the sign yourself. Signed shifts are easy, by just
> replicating the top bit, e.g.
>
> wire [15:0] shifted_a = {(16){a[15]}, a} >> shift;
>
>> I wasn't aware that the Verilog standard covers things like drive
>> strengths and transistor models. Can you refer me to info on this? Is
>> this capability good enough to replace Spice?
>
> No way. It's good enough to model IOs and wired-and busses like I²C.
> You'll find a section about that in any reasonable Verilog book, or when you
> google for "Verilog transistor primitives":
>
> http://electrosofts.com/verilog/primitives.html
I'm pretty sure you can model an I2C bus in VHDL.
>> You are gleaning a large conclusion from very little information. I
>> don't accept your conclusion that "the switch has been done". How many
>> of these companies have said "all new designs are in Verilog?"
>
> There are certainly too many semiconductor companies around Munich to give a
> definitive answer ;-). The companies I know of have all made the switch,
> and that includes the by far biggest one.
But you don't actually say how you know they have "made the switch".
You say they are hiring both Verilog and VHDL people, that's not proof
of "making the switch". When they stop offering VHDL models of memory
or other parts, or you can offer some real evidence like an employee
saying they don't use VHDL anymore... then I'll believe.
>> I don't think the Cooley test was very useful or well controlled. Your
>> statement was "Verilog is about 3 times as productive as VHDL". How
>> many of the Verilog programmers finished in 30 minutes?
>
> Well, none of the VHDL programmer did finish in 90 minutes. The 3x figure
> comes from the observation, that VHDL for the same job typically has a 3x
> line count as Verilog, while the LoCs per day are the same for both
> languages (and indeed the LoCs per day doesn't vary much between different
> languages).
Again, where can you point me to for this info?
>> Judging from the comments made by a couple of them I think they were not
>> professional programmers in the sense of banging out code every day.
>> Anyone who has problems with type conversions in VHDL is not up to speed
>> and should not be in anything remotely like the Cooley race.
>
> However, that observation coincides with my observation that all VHDL
> designers had problems with the typing system, and were banging out code
> every day. You assume a level of VHDL knowledge that I've never seen.
Your observation from what, 15 years ago? Using what tools, I think
they were officially certified crappy, no? I'm assuming the level of
experience with VHDL that anyone who has used it for more than a month
should have.
Read the code I gave you above. Tell me how long it would take you to
learn that... It would have saved your coworker how many hours?
>> Or the training. I assume now you are talking about the people you
>> worked with who never figured out how to do type conversion or how to
>> avoid needing type conversion. I could explain that topic in 15 minutes
>> of instruction.
>
> So please explain how to index an array with std_logic and avoiding type
> conversion.
Why do you have to avoid type conversion??? Is it too hard to type
"to_integer"? Also, few VHDL people use std_logic_vector anymore unless
it is required for I/O. Unsigned and signed are much better types.
>> I remember the first time I heard the amplifier statement about Forth.
>> I have often wondered if it is so much an amplifier as it is a filter.
>> If you are a great programmer then you can deal with the various issues
>> of Forth just as you could deal with the various issues of any other
>> language... except maybe VHDL which seems to be a fatal blow to some.
>
> VHDL's issues certainly drag me down: It's overly complex and therefore
> takes more time to learn, the type system is worse than useless, and not
> designed for creating circuits (I wonder what it was designed for), and some
> parts of the language standards have simply been wrong (like the shift
> operators in numeric_std, which were added as aftertought and misspecified).
I'd like to know details of the shift operator problems.
>> If you are a lesser programmer I think the issues of Forth drag you down.
>
> Yes. But to call them "issues" implies that good programmers work around
> them, it doesn't help them to gain speed, it just doesn't drag them down a
> lot. I don't think the problematic parts of Forth for lesser programmers
> are real issues for the good programmers.
No, because you took the time to learn how to deal with the language and
worked with the limitations while exploiting the unique features.
Something you failed to do with VHDL which may not be your fault. It
sounds like you had some really bad tools and it may have been before
they smoothed off some of the rough edges of VHDL.
>> Heck, you like statistical evidence so much, Forth has always been a
>> back water language in terms of popularity and it has dropped off over
>> the years. Does that mean it is a poor choice of language? There seem
>> to be a huge number of people who try it and simply drop it out of pure
>> frustration. So Verilog is like C and VHDL is like Ada^H^H^H Forth?
>
> VHDL is certainly like Ada, and nowhere like Forth. Verilog is like C, I'm
> fine with that description. I'd love to see a HDL which is based on Forth,
> and works like Forth - simple, stack-based, implicit where possible (e.g.
> most modules have a single clock and a single reset - no need to name
> those), with tools optimized for the 90% you need.
>
> Ada and Forth are certainly two very opposite directions of programming
> languages for the same job (low-level control stuff).
There are different ways of being similar. Both are archane, both are
not very popular and both are not so easy to learn to use proficiently.
One difference is I don't think usage of Ada has fallen off much over
the years but I may be mistaken.
>>> It might be that Verilog is an amplifier; however, given how much easier
>>> people perceive it is to learn, I much doubt it.
>>
>> I won't argue that Verilog is not quicker to learn. I just think most
>> of your bias against VHDL is based on ancient experiences using poor
>> tools. I won't recommend that you try it again because I think it is
>> just against your grain no matter how well others are able to use it.
>
> It wasn't that ancient; the tools are of course better now (I hope the tools
> always get better), but yes, VHDL certainly is not for me, so I won't
> reconsidder it. I don't think it has anything of value to offer.
>
> We had switched tools from a VHDL-oriented vendor (Mentor Graphics) to
> Cadence after we did the VHDL-Verilog switch at Mikron; that switch was
> driven by fab support, but the tools from Cadence support Verilog better
> than VHDL. However, the Siemens HL experience before was with Synopsys,
> which has even better tools than Cadence - they had the best tools for VHDL
> available at that time, so if it was a tools issue, I would be rather
> surprised.
Didn't you tell me you had to write your test benches in both languages?
Was that because of your ASIC vendor and not the tools?
I have not seen any of the absurd tool related problems you reported. I
work with FPGAs though, not ASICs. I have seen plenty of problems, but
was when I first was learning VHDL back in 1995 nearly 20 years ago.
> Verilog has fixed several issues it had 15 years ago, as well. The most
> important is IMHO the "always @*" for asynchronous blocks in Verilog 2001.
> VHDL copied that in VHDL-2008, with a "process(all)" statement.
Yep!
BTW, none of the things you list above were any of the issues with
Verilog I recall being told to worry about. They were more subtle
things like what happens when you assign an 8 bit vector to a 9 bit
vector (or is it the other way around?) VHDL requires you to tell it
what you want to happen. I believe Verilog makes assumptions without
even a warning. There are some others having to do with simulations but
I just don't recall.
--
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