Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #49233 > unrolled thread

Re: Jazelle?

Back to article view | Back to comp.lang.forth

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 10:31 +0100
    Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-20 10:14 +0000
      Re: Jazelle? Chris Curl <ccurl609@gmail.com> - 2016-07-20 05:37 -0700
        Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-20 13:36 +0000
      Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-20 13:06 +0000
      Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 14:49 +0100
        Re: Jazelle? hughaguilar96@gmail.com - 2016-07-20 08:48 -0700
        Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-20 14:35 +0000
          Re: Jazelle? mm0fmf <none@invalid.com> - 2016-07-20 17:39 +0100
          Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 20:30 +0100
            Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 15:35 -0400
              Re: Jazelle? mhx@iae.nl - 2016-07-20 13:27 -0700
                Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-21 09:41 +0000
              Re: Jazelle? hughaguilar96@gmail.com - 2016-07-21 17:24 -0700
          Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-21 10:43 +0000
            Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-21 12:44 +0000
              Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-21 22:59 +0100
                Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:42 +0000
                  Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-22 12:03 +0100
                    Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-22 09:05 -0400
                      Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 10:09 -0500
                      Re: Jazelle? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-07-22 19:20 +0300
                    Re: Jazelle? Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 09:35 -0700
            Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-25 10:43 +0000
              Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-26 11:41 +0100
                Re: Jazelle? Julian Fondren <julian.fondren@gmail.com> - 2016-07-26 04:26 -0700
                  Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-26 11:20 -0400
    Re: Jazelle? Doug Hoffman <glidedog@gmail.com> - 2016-07-20 06:44 -0400
      Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 14:52 +0100
        Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-20 14:33 +0000
        Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 10:52 -0400
          Re: Jazelle? alister <alister.ware@ntlworld.com> - 2016-07-20 15:40 +0000
            Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 11:46 -0400
            Re: Jazelle? hughaguilar96@gmail.com - 2016-07-20 09:25 -0700
      Re: Jazelle? hughaguilar96@gmail.com - 2016-07-20 09:22 -0700
        Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 13:14 -0400
          Re: Jazelle? hughaguilar96@gmail.com - 2016-07-20 21:44 -0700
            Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-21 01:32 -0400
              Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 02:21 -0500
            Re: Jazelle? Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 17:13 -0700
              Re: Jazelle? hughaguilar96@gmail.com - 2016-07-21 17:42 -0700
              Re: Jazelle? humptydumpty <ouatubi@gmail.com> - 2016-07-23 10:08 -0700
                Re: Jazelle? hughaguilar96@gmail.com - 2016-07-23 13:55 -0700
                  Re: Jazelle? humptydumpty <ouatubi@gmail.com> - 2016-07-24 02:22 -0700
    Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 10:56 -0400
    Re: Jazelle? Brad Eckert <hwfwguy@gmail.com> - 2016-07-20 10:54 -0700
      Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-20 13:33 -0500
        Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 16:51 -0400
          Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-20 17:09 -0500
            Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 18:12 -0400
              Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-20 18:41 -0500
                Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 21:01 -0400

Page 3 of 3 — ← Prev page 1 2 [3]

#49298

On Thursday, July 21, 2016 at 5:13:56 PM UTC-7, Brad Eckert wrote:
> On Wednesday, July 20, 2016 at 9:44:29 PM UTC-7, hughag...@gmail.com wrote:
> > This Gareth guy reminds me of Elizabeth Rather.
> > 
> > Gareth doesn't see any point to RPN, so he criticizes it and says it ought not to be done.
> > 
> > Elizabeth Rather doesn't see any point to local variables or quotations or pretty much any intermediate-level computer-science concepts, so she makes a rule stating that all of this is banned and that anybody who writes Forth code with these features is non-standard --- that rule is ANS-Forth --- Elizabeth Rather is all about telling people what they can't do, rather than what they can do.
> 
> Elizabeth has defended the use of local variables for Windows programming. For embedded stuff, I implemented locals and never used them once. Oh, well. It's probably that ANS Locals don't support enough scoping. You might want locals to apply to a range of words, not just one.

In SwiftForth-v2 the use of (LOCAL) would crash SwiftForth --- does this mean that local variables were used for Windows programming only after SwiftForth-v3 was released?

ANS-Forth has poor support for locals in the following ways:
1.) Locals use TO rather than @ and ! etc., so there is no way to obtain the address of a local.
2.) Locals only work for cell-sized data, but not for floats etc..
3.) The parameters for LOCALS| are backwards (my { solves this, and it is ANS-Forth).
4.) Locals in the parent function are not accessible in the quotation (my rquotations solves this, but are not ANS-Forth).

Locals are one of those features that only become necessary when you write complicated functions. A lot of embedded code isn't very complicated. Embedded programs may be complicated in the sense that you have to figure out what values should go out the DAC and what the values mean that come in on the ADC, and timing is always a very important issue that has to be gotten correct. The code however is typically not very complicated --- the functions are short and simple --- they may not need locals, but can just use >R R@ R> etc. instead. If you are using global variables for local data however, then you are wasting memory --- OTOH, global variables are very fast on a processor such as the 8032 that lacks an indexed addressing-mode, so as long as you have enough memory for your program then you should use global variables (there is no point in having memory left over unused by your program).

Straight Forth will have locals that work --- Straight Forth is for desktop-computers --- embedded micro-controller issues are irrelevant to to Straight Forth.

[toc] | [prev] | [next] | [standalone]

#49367

On Friday, July 22, 2016 at 3:13:56 AM UTC+3, Brad Eckert wrote:
> On Wednesday, July 20, 2016 at 9:44:29 PM UTC-7, hughag...@gmail.com wrote:
> > This Gareth guy reminds me of Elizabeth Rather.
> > 
> > Gareth doesn't see any point to RPN, so he criticizes it and says it ought not to be done.
> > 
> > Elizabeth Rather doesn't see any point to local variables or quotations or pretty much any intermediate-level computer-science concepts, so she makes a rule stating that all of this is banned and that anybody who writes Forth code with these features is non-standard --- that rule is ANS-Forth --- Elizabeth Rather is all about telling people what they can't do, rather than what they can do.
> 
> Elizabeth has defended the use of local variables for Windows programming. For embedded stuff, I implemented locals and never used them once. Oh, well. It's probably that ANS Locals don't support enough scoping. You might want locals to apply to a range of words, not just one.
> 
> Just to go completely off topic, I doubt Gareth has ever been run down by a crazy surfer.

Hi!

> You might want locals to apply to a range of words, not just one.

A particular case of that is to bind variables to a local scope of a word:

: ends> r> ;
: end   >r ; immediate
: bind  ends> ; immediate
: loc  postpone dup postpone @ postpone 2>r ends> postpone r> postpone r> postpone ! postpone end ; immediate

And use like:

: act  ( ... ) \ with preservation of X Y Z
  ( pre actions )
  bind X loc Y loc Z loc
    ( call whatever words that modifies X Y Z )
  end
  ( post actions; X Y Z have have pre-'bind' values)
;

--
Have a nice day,
humptydumpty 

[toc] | [prev] | [next] | [standalone]

#49379

On Saturday, July 23, 2016 at 10:08:24 AM UTC-7, humptydumpty wrote:
> On Friday, July 22, 2016 at 3:13:56 AM UTC+3, Brad Eckert wrote:
> > On Wednesday, July 20, 2016 at 9:44:29 PM UTC-7, hughag...@gmail.com wrote:
> > > This Gareth guy reminds me of Elizabeth Rather.
> > > 
> > > Gareth doesn't see any point to RPN, so he criticizes it and says it ought not to be done.
> > > 
> > > Elizabeth Rather doesn't see any point to local variables or quotations or pretty much any intermediate-level computer-science concepts, so she makes a rule stating that all of this is banned and that anybody who writes Forth code with these features is non-standard --- that rule is ANS-Forth --- Elizabeth Rather is all about telling people what they can't do, rather than what they can do.
> > 
> > Elizabeth has defended the use of local variables for Windows programming. For embedded stuff, I implemented locals and never used them once. Oh, well. It's probably that ANS Locals don't support enough scoping. You might want locals to apply to a range of words, not just one.
> > 
> > Just to go completely off topic, I doubt Gareth has ever been run down by a crazy surfer.
> 
> Hi!
> 
> > You might want locals to apply to a range of words, not just one.
> 
> A particular case of that is to bind variables to a local scope of a word:
> 
> : ends> r> ;
> : end   >r ; immediate
> : bind  ends> ; immediate
> : loc  postpone dup postpone @ postpone 2>r ends> postpone r> postpone r> postpone ! postpone end ; immediate
> 
> And use like:
> 
> : act  ( ... ) \ with preservation of X Y Z
>   ( pre actions )
>   bind X loc Y loc Z loc
>     ( call whatever words that modifies X Y Z )
>   end
>   ( post actions; X Y Z have have pre-'bind' values)
> ;
> 
> --
> Have a nice day,
> humptydumpty

Forth is an extensible language, so it is possible to extend Forth to have features such as you and I have implemented. These features are way beyond anything that C offers! This is really the whole point of Forth. People who get involved in an infix-versus-postfix argument are totally missing the point. 

The important thing however, is to never let anybody make a rule stating that Forth can't be extended, and that her version of Forth is the Standard that everybody must adhere to lest they get banished to non-standard purgatory --- if this happens, then Forth becomes a statically defined language like C --- Forth will be nothing more than an RPN version of C, which is totally pointless, and rather ugly.

[toc] | [prev] | [next] | [standalone]

#49385

On Saturday, July 23, 2016 at 11:55:19 PM UTC+3, hughag...@gmail.com wrote:
> On Saturday, July 23, 2016 at 10:08:24 AM UTC-7, humptydumpty wrote:
> > On Friday, July 22, 2016 at 3:13:56 AM UTC+3, Brad Eckert wrote:
> > > On Wednesday, July 20, 2016 at 9:44:29 PM UTC-7, hughag...@gmail.com wrote:
> > > > This Gareth guy reminds me of Elizabeth Rather.
> > > > 
> > > > Gareth doesn't see any point to RPN, so he criticizes it and says it ought not to be done.
> > > > 
> > > > Elizabeth Rather doesn't see any point to local variables or quotations or pretty much any intermediate-level computer-science concepts, so she makes a rule stating that all of this is banned and that anybody who writes Forth code with these features is non-standard --- that rule is ANS-Forth --- Elizabeth Rather is all about telling people what they can't do, rather than what they can do.
> > > 
> > > Elizabeth has defended the use of local variables for Windows programming. For embedded stuff, I implemented locals and never used them once. Oh, well. It's probably that ANS Locals don't support enough scoping. You might want locals to apply to a range of words, not just one.
> > > 
> > > Just to go completely off topic, I doubt Gareth has ever been run down by a crazy surfer.
> > 
> > Hi!
> > 
> > > You might want locals to apply to a range of words, not just one.
> > 
> > A particular case of that is to bind variables to a local scope of a word:
> > 
> > : ends> r> ;
> > : end   >r ; immediate
> > : bind  ends> ; immediate
> > : loc  postpone dup postpone @ postpone 2>r ends> postpone r> postpone r> postpone ! postpone end ; immediate
> > 
> > And use like:
> > 
> > : act  ( ... ) \ with preservation of X Y Z
> >   ( pre actions )
> >   bind X loc Y loc Z loc
> >     ( call whatever words that modifies X Y Z )
> >   end
> >   ( post actions; X Y Z have have pre-'bind' values)
> > ;
> > 
> > --
> > Have a nice day,
> > humptydumpty
> 
> Forth is an extensible language, so it is possible to extend Forth to have features such as you and I have implemented. These features are way beyond anything that C offers! This is really the whole point of Forth. People who get involved in an infix-versus-postfix argument are totally missing the point. 
> 
> The important thing however, is to never let anybody make a rule stating that Forth can't be extended, and that her version of Forth is the Standard that everybody must adhere to lest they get banished to non-standard purgatory --- if this happens, then Forth becomes a statically defined language like C --- Forth will be nothing more than an RPN version of C, which is totally pointless, and rather ugly.


Hi!

Complaints ON

That is one of possibly bad scenarios.

Another one is to "cripple" "Conceptual Forth Virtual Machine".
Let me speak my mind.  I consider three conceptual levels in programming Forth:

L0. Language of Values, Adresses, Mathematics on values&adresses - near of what hardware provides.

L1. Forth Virtual Machine: Data Stack, Return Stack(first as stack of continuations,
second as temporary storage), Dictionary (linked-list alike, last defined is first searched),
States (interpreting/compiling), Implementation of Forth Virtual Machine near as possible to hardware.

L2. Application: Straightforwardly translate ideas, concepts to L0 using L1.

There is a danger to push complexity through "facilities" from L2 to L1. Then 
"Conceptual Forth VM" begins to look complex to understand.

That is contrary of what C.H.Moore does:
    Push complexity from L1:
        - to L0 through creating Forth Hardware;
        - to L3 and adopting other ways to use those news FVM.

Another set of things:
I think that is a shame to not use the freedom that FVM provides. Also I think
that before to adopt a Standard, every degree of freedom that FVM provides
should be explored and included into something like a "Guide of Use".
I feel puzzled that usage of continuations was discouraged, and their usage like
'end ends>' pair or rquotations was not used along tens of years of Forth!

Complaints OFF

Uff.. Done! :)
--
Have a nice day,
humptydumpty

[toc] | [prev] | [next] | [standalone]

#49245

On 7/20/2016 5:31 AM, gareth G4SDW GQRP #3339 wrote:
> "Paul" <paul@pcserviceselectronics.co.uk> wrote in message
> news:MPG.31f93e8b429c8383989804@172.16.0.1...
>> In article <nmn4gf$p1o$2@news.albasani.net>, tnp@invalid.invalid says...
>>> On 20/07/16 01:25, rickman wrote:
>>>> On 7/18/2016 5:50 AM, gareth G4SDW GQRP #3339 wrote:
>>>>> I wonder if anyone has done any experiments to determine what the
>>>>> Jazelle byte codes are, for use of such things should produce code
>>>>> that is even more compact than Thumb?
>>>>>
>>>>> e.g single steppint code and then examining the changes that have
>>>>> been wrought by each code, allowing for some extra bytes as
>>>>> addresses or immediate data.
>>>>
>>>> If you want high code density, you should learn Forth.  It can support
>>>> a
>>>> complete Forth compiler in as little as 16 kB.
>>>>
>>> Indeed. More compact than assembler really!
>
> But Forth _IS_ assembler, for it is based on the prior published
> art of the KDF9 computer architecture along with its drop, dup, data and
> return stacks.

Why do you say Forth is based on any particular computer design?  Forth 
emulates an abstract stack based CPU.  The KDF9 is one of many which had 
been designed by the time Forth was invented.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49259

On Wednesday, July 20, 2016 at 2:31:46 AM UTC-7, gareth G4SDW GQRP #3339 wrote:
> But Forth _IS_ assembler, for it is based on the prior published
> art of the KDF9 computer architecture along with its drop, dup, data and 
> return stacks.
> 
Chuck was influenced by the Burroughs B5500, a computer from approximately the same time (KDF9 came online in 1964, B5000 in 1961). He must have really liked the B5500 because you can see a lot of its ideas in his ShBoom 32-bit CPU design (about 1985).

You could say that Forth and C are both assembly languages. C is a portable assembler with types. Forth is a portable assembler with extensibility. Both have quirky system dependencies that can only be lived with.

[toc] | [prev] | [next] | [standalone]

#49260

On 7/20/2016 12:54 PM, Brad Eckert wrote:
> On Wednesday, July 20, 2016 at 2:31:46 AM UTC-7, gareth G4SDW GQRP #3339 wrote:
>> But Forth _IS_ assembler, for it is based on the prior published
>> art of the KDF9 computer architecture along with its drop, dup, data and
>> return stacks.
>>
> Chuck was influenced by the Burroughs B5500, a computer from approximately the same time (KDF9 came online in 1964, B5000 in 1961). He must have really liked the B5500 because you can see a lot of its ideas in his ShBoom 32-bit CPU design (about 1985).
>
> You could say that Forth and C are both assembly languages. C is a portable assembler with types. Forth is a portable assembler with extensibility. Both have quirky system dependencies that can only be lived with.
>
In the early 70's I designed and built my own CPU, I was impressed by 
the B5500 and implemented two stacks, but it was not a classical Forth 
CPU but a mixture of register and stack CPU. The TOS could be one of the 
operands or destination but the second operand was immediate, register, 
or register indirect. But since the CPU was micro-programmable, it could 
have been easily changed but I was not aware of Forth at the time.

One of these days I would like to create the design again with a FPGA, I 
do have some notes I kept on the design.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#49264

On 7/20/2016 2:33 PM, Cecil Bayona wrote:
> On 7/20/2016 12:54 PM, Brad Eckert wrote:
>> On Wednesday, July 20, 2016 at 2:31:46 AM UTC-7, gareth G4SDW GQRP
>> #3339 wrote:
>>> But Forth _IS_ assembler, for it is based on the prior published
>>> art of the KDF9 computer architecture along with its drop, dup, data and
>>> return stacks.
>>>
>> Chuck was influenced by the Burroughs B5500, a computer from
>> approximately the same time (KDF9 came online in 1964, B5000 in 1961).
>> He must have really liked the B5500 because you can see a lot of its
>> ideas in his ShBoom 32-bit CPU design (about 1985).
>>
>> You could say that Forth and C are both assembly languages. C is a
>> portable assembler with types. Forth is a portable assembler with
>> extensibility. Both have quirky system dependencies that can only be
>> lived with.
>>
> In the early 70's I designed and built my own CPU, I was impressed by
> the B5500 and implemented two stacks, but it was not a classical Forth
> CPU but a mixture of register and stack CPU. The TOS could be one of the
> operands or destination but the second operand was immediate, register,
> or register indirect. But since the CPU was micro-programmable, it could
> have been easily changed but I was not aware of Forth at the time.
>
> One of these days I would like to create the design again with a FPGA, I
> do have some notes I kept on the design.

If you get serious about this, send me a block diagram and the 
instruction set and I'd be happy to give some pointers.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49265

On 7/20/2016 3:51 PM, rickman wrote:
> On 7/20/2016 2:33 PM, Cecil Bayona wrote:
>> On 7/20/2016 12:54 PM, Brad Eckert wrote:
>>> On Wednesday, July 20, 2016 at 2:31:46 AM UTC-7, gareth G4SDW GQRP
>>> #3339 wrote:
>>>> But Forth _IS_ assembler, for it is based on the prior published
>>>> art of the KDF9 computer architecture along with its drop, dup, data
>>>> and
>>>> return stacks.
>>>>
>>> Chuck was influenced by the Burroughs B5500, a computer from
>>> approximately the same time (KDF9 came online in 1964, B5000 in 1961).
>>> He must have really liked the B5500 because you can see a lot of its
>>> ideas in his ShBoom 32-bit CPU design (about 1985).
>>>
>>> You could say that Forth and C are both assembly languages. C is a
>>> portable assembler with types. Forth is a portable assembler with
>>> extensibility. Both have quirky system dependencies that can only be
>>> lived with.
>>>
>> In the early 70's I designed and built my own CPU, I was impressed by
>> the B5500 and implemented two stacks, but it was not a classical Forth
>> CPU but a mixture of register and stack CPU. The TOS could be one of the
>> operands or destination but the second operand was immediate, register,
>> or register indirect. But since the CPU was micro-programmable, it could
>> have been easily changed but I was not aware of Forth at the time.
>>
>> One of these days I would like to create the design again with a FPGA, I
>> do have some notes I kept on the design.
>
> If you get serious about this, send me a block diagram and the
> instruction set and I'd be happy to give some pointers.
>
Thanks for the offer, I will let you know when I am ready to start the 
project, but it will be a few months before I am close to starting on 
it, among other things I need to learn VHDL first, and thinks keep 
getting in the way. Too many projects that I'm working on.

This morning I received a book "16-Bit Microprocessors" it has a lot of 
useful information on older CPU chips, so more reading to do.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#49266

On 7/20/2016 6:09 PM, Cecil Bayona wrote:
> On 7/20/2016 3:51 PM, rickman wrote:
>> On 7/20/2016 2:33 PM, Cecil Bayona wrote:
>>> On 7/20/2016 12:54 PM, Brad Eckert wrote:
>>>> On Wednesday, July 20, 2016 at 2:31:46 AM UTC-7, gareth G4SDW GQRP
>>>> #3339 wrote:
>>>>> But Forth _IS_ assembler, for it is based on the prior published
>>>>> art of the KDF9 computer architecture along with its drop, dup, data
>>>>> and
>>>>> return stacks.
>>>>>
>>>> Chuck was influenced by the Burroughs B5500, a computer from
>>>> approximately the same time (KDF9 came online in 1964, B5000 in 1961).
>>>> He must have really liked the B5500 because you can see a lot of its
>>>> ideas in his ShBoom 32-bit CPU design (about 1985).
>>>>
>>>> You could say that Forth and C are both assembly languages. C is a
>>>> portable assembler with types. Forth is a portable assembler with
>>>> extensibility. Both have quirky system dependencies that can only be
>>>> lived with.
>>>>
>>> In the early 70's I designed and built my own CPU, I was impressed by
>>> the B5500 and implemented two stacks, but it was not a classical Forth
>>> CPU but a mixture of register and stack CPU. The TOS could be one of the
>>> operands or destination but the second operand was immediate, register,
>>> or register indirect. But since the CPU was micro-programmable, it could
>>> have been easily changed but I was not aware of Forth at the time.
>>>
>>> One of these days I would like to create the design again with a FPGA, I
>>> do have some notes I kept on the design.
>>
>> If you get serious about this, send me a block diagram and the
>> instruction set and I'd be happy to give some pointers.
>>
> Thanks for the offer, I will let you know when I am ready to start the
> project, but it will be a few months before I am close to starting on
> it, among other things I need to learn VHDL first, and thinks keep
> getting in the way. Too many projects that I'm working on.

Or you could learn Verilog which should have a *much* shorter learning 
curve.  I use VHDL because it is what I learned.  VHDL does have some 
good simulation features though.


> This morning I received a book "16-Bit Microprocessors" it has a lot of
> useful information on older CPU chips, so more reading to do.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49267

On 7/20/2016 5:12 PM, rickman wrote:
> On 7/20/2016 6:09 PM, Cecil Bayona wrote:
>> On 7/20/2016 3:51 PM, rickman wrote:
>>> On 7/20/2016 2:33 PM, Cecil Bayona wrote:
>>>> On 7/20/2016 12:54 PM, Brad Eckert wrote:
>>>>> On Wednesday, July 20, 2016 at 2:31:46 AM UTC-7, gareth G4SDW GQRP
>>>>> #3339 wrote:
>>>>>> But Forth _IS_ assembler, for it is based on the prior published
>>>>>> art of the KDF9 computer architecture along with its drop, dup, data
>>>>>> and
>>>>>> return stacks.
>>>>>>
>>>>> Chuck was influenced by the Burroughs B5500, a computer from
>>>>> approximately the same time (KDF9 came online in 1964, B5000 in 1961).
>>>>> He must have really liked the B5500 because you can see a lot of its
>>>>> ideas in his ShBoom 32-bit CPU design (about 1985).
>>>>>
>>>>> You could say that Forth and C are both assembly languages. C is a
>>>>> portable assembler with types. Forth is a portable assembler with
>>>>> extensibility. Both have quirky system dependencies that can only be
>>>>> lived with.
>>>>>
>>>> In the early 70's I designed and built my own CPU, I was impressed by
>>>> the B5500 and implemented two stacks, but it was not a classical Forth
>>>> CPU but a mixture of register and stack CPU. The TOS could be one of
>>>> the
>>>> operands or destination but the second operand was immediate, register,
>>>> or register indirect. But since the CPU was micro-programmable, it
>>>> could
>>>> have been easily changed but I was not aware of Forth at the time.
>>>>
>>>> One of these days I would like to create the design again with a
>>>> FPGA, I
>>>> do have some notes I kept on the design.
>>>
>>> If you get serious about this, send me a block diagram and the
>>> instruction set and I'd be happy to give some pointers.
>>>
>> Thanks for the offer, I will let you know when I am ready to start the
>> project, but it will be a few months before I am close to starting on
>> it, among other things I need to learn VHDL first, and thinks keep
>> getting in the way. Too many projects that I'm working on.
>
> Or you could learn Verilog which should have a *much* shorter learning
> curve.  I use VHDL because it is what I learned.  VHDL does have some
> good simulation features though.
>
>
>> This morning I received a book "16-Bit Microprocessors" it has a lot of
>> useful information on older CPU chips, so more reading to do.
>
I wondered about Verilog instead of VHDL, I've seen some CPUs in Verilog 
and the code seemed easier do understand. I do have at present a bunch 
of books on VHDL and some of them look quite good, I'll have to order a 
book or two on Verilog and make a comparison. I also bookmarked some 
sites on MyVHL but there is a lack of information on actually using it.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#49268

On 7/20/2016 7:41 PM, Cecil Bayona wrote:
> On 7/20/2016 5:12 PM, rickman wrote:
>> On 7/20/2016 6:09 PM, Cecil Bayona wrote:
>>> On 7/20/2016 3:51 PM, rickman wrote:
>>>> On 7/20/2016 2:33 PM, Cecil Bayona wrote:
>>>>> On 7/20/2016 12:54 PM, Brad Eckert wrote:
>>>>>> On Wednesday, July 20, 2016 at 2:31:46 AM UTC-7, gareth G4SDW GQRP
>>>>>> #3339 wrote:
>>>>>>> But Forth _IS_ assembler, for it is based on the prior published
>>>>>>> art of the KDF9 computer architecture along with its drop, dup, data
>>>>>>> and
>>>>>>> return stacks.
>>>>>>>
>>>>>> Chuck was influenced by the Burroughs B5500, a computer from
>>>>>> approximately the same time (KDF9 came online in 1964, B5000 in
>>>>>> 1961).
>>>>>> He must have really liked the B5500 because you can see a lot of its
>>>>>> ideas in his ShBoom 32-bit CPU design (about 1985).
>>>>>>
>>>>>> You could say that Forth and C are both assembly languages. C is a
>>>>>> portable assembler with types. Forth is a portable assembler with
>>>>>> extensibility. Both have quirky system dependencies that can only be
>>>>>> lived with.
>>>>>>
>>>>> In the early 70's I designed and built my own CPU, I was impressed by
>>>>> the B5500 and implemented two stacks, but it was not a classical Forth
>>>>> CPU but a mixture of register and stack CPU. The TOS could be one of
>>>>> the
>>>>> operands or destination but the second operand was immediate,
>>>>> register,
>>>>> or register indirect. But since the CPU was micro-programmable, it
>>>>> could
>>>>> have been easily changed but I was not aware of Forth at the time.
>>>>>
>>>>> One of these days I would like to create the design again with a
>>>>> FPGA, I
>>>>> do have some notes I kept on the design.
>>>>
>>>> If you get serious about this, send me a block diagram and the
>>>> instruction set and I'd be happy to give some pointers.
>>>>
>>> Thanks for the offer, I will let you know when I am ready to start the
>>> project, but it will be a few months before I am close to starting on
>>> it, among other things I need to learn VHDL first, and thinks keep
>>> getting in the way. Too many projects that I'm working on.
>>
>> Or you could learn Verilog which should have a *much* shorter learning
>> curve.  I use VHDL because it is what I learned.  VHDL does have some
>> good simulation features though.
>>
>>
>>> This morning I received a book "16-Bit Microprocessors" it has a lot of
>>> useful information on older CPU chips, so more reading to do.
>>
> I wondered about Verilog instead of VHDL, I've seen some CPUs in Verilog
> and the code seemed easier do understand. I do have at present a bunch
> of books on VHDL and some of them look quite good, I'll have to order a
> book or two on Verilog and make a comparison. I also bookmarked some
> sites on MyVHL but there is a lack of information on actually using it.

I don't know I've ever thought Verilog is easier to understand than 
VHDL.  The main drawback is VHDL enforces type checking with a passion 
so it can be a bit hard to learn.  Once you get over the learning curve 
the code can be a bit verbose to type.  But otherwise I find my VHDL is 
much easier to read than most Verilog I read.

Using VHDL tends to encourage a bit of discipline in coding style that I 
often find lacking in Verilog.  For example, modules can be instantiated 
by named association or by positional association in both languages I 
believe.  All the Verilog code I've seen use positional association 
while the vast majority of VHDL code uses named association.  But mostly 
it is the white space and formatting I find differ a lot.  Much Verilog 
seems to be left justified with very little white space while the vast 
majority of the VHDL I read is well organized with good indentation and 
white space to separate units.

While VHDL has its flaws, there is nothing inherent in VHDL that makes 
it hard to read.

-- 

Rick C

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.forth

csiph-web