Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation

From	rickman <gnuarm@gmail.com>
Newsgroups	comp.lang.forth
Subject	Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation
Date	2013-07-05 19:21 -0400
Organization	A noiseless patient Spider
Message-ID	<kr7k4f$end$2@dont-email.me> (permalink)
References	(17 earlier) <7x1u7e6xg8.fsf@ruckus.brouhaha.com> <kr4b85$t1o$1@dont-email.me> <7x38ruxh8o.fsf@ruckus.brouhaha.com> <kr7c6i$end$1@dont-email.me> <7x61wo8xr2.fsf@ruckus.brouhaha.com>

Show all headers | View raw

On 7/5/2013 6:09 PM, Paul Rubin wrote:
> rickman<gnuarm@gmail.com>  writes:
>>> hopefully agree that it's bloody obvious that if two chips are made with
>>> the same process and one of them has 4x more circuitry than the other,
>>> the bigger one is likely to have more total leakage current
>> Yes, if you want to talk in abstractions then sure, I agree.  But what
>> is the point of that?
>
> If the abstractions are correct, it means we can justify statements
> about the domain without having to bog down in specific examples.
> That's why they are so powerful.  If we know that adding two odd numbers
> always gives an even number, we don't have to actually do the addition
> to discover whether 12345+98763 is odd or even.
>
> In the Cortex M0+ case, it looks to me from data sheets that the part
> you mentioned uses quite a lot more power than recent MSP430's.  That of
> course may not be a direct result of the larger word size.
>
>>> I look at the sample code that GA has posted, and the pain level
>>> apparent in that code, and I can only conclude that nobody knows how.
>> I like to think I know how.
>
> I think you are kidding yourself, if you believe you can code typical
> algorithms on the GA144 with the ease people code them for MCU's.

Ok, I think this conversation is near an end.  I believe you have done 
very little to learn about the GA144.  Here you are doubting what I have 
learned about the chip without knowing much about it yourself.  Not much 
point in continuing the conversation if you are going to take that 
approach.

>> Ok, AES encryption may not be suitable for the GA144 if it uses 100
>> out of 144 cores.  It is also likely not suitable for the 8 bitter
>> chips you have been talking about.
>
> It works fine (if slowly) on 8-bitters and is quite easy to implement on
> them.  That was one of its design goals.  MD5 is another example, very
> easy on an MCU (given the code space) but a big pain on the GA.  Here is
> pseudocode for SHA-1:
>
>    http://en.wikipedia.org/wiki/Sha1#SHA-1_pseudocode
>
> I remember coding this in C in a few hours (most of the hassle was
> making sure it worked correctly on both little and big endian cpu's).
> Doing it on the GA144 looks like an order of magnitude more work.

So why would it be a pain on the GA144?  Is it just code space?  I have 
no interest in learning about the application for the purpose of this 
discussion.  I have looked at the GA144 for the type of embedded work I 
do and it looks very good for that other than the issues I have with the 
limited I/O voltages (it does 1.8 volt CMOS only) and the inability to 
determine timing for high speed work which is really a company issue 
(they don't want to take the measurements or release the info).

>> I haven't read all the app notes, but I am pretty sure it doesn't take
>> months to learn how to use the GA144.  I learned what I know in a few
>> weeks.  I did not get to the point of mastering all the tools however.
>
> It's not a matter of mastering tools.  The chip itself has intrinsic
> limitations that makes straightforward tasks difficult no matter how
> well you master the tools.

I assume you mean memory.  Every MCU out there has memory limitations. 
The GA144 has a fixed memory size, yes.  Even with that it will accept 
external memory.

>>>> figure out how to use a single CPU to do multiple asynchronous
>>>> tasks, interrupts, multi-threading, etc... not simple stuff ...
>
> This is the 21st century and dealing with concurrency (whether through
> multitasking or whatever) is part of every working programmer's toolkit.

Now you are agreeing with me.  I said you have already learned how to 
manage this stuff in conventional processors while you have not learned 
how to do it in the GA devices.  What you have not acknowledged is that 
it is *NOT* easy to do on conventional CPUs, it requires adherence to a 
number of practices and *someone* had to do a lot of leg work ahead of 
you.

On the GA144 there are numerous features that help you with the 
concurrency, you just have to design your implementation to match the 
granularity of this chip.  Not so hard if you ever pick up a document 
and read about the chip.  Have you?  How far did you get?

>> Uh, I don't think you will have much luck getting any MCU without an
>> internal oscillator to run from a crystal.
>
> I'm not a hardware guy but on MCU data sheets I see pins where you put a
> crystal, so I guess those are internal oscillators.

Yes, most MCUs have them because they are simple to add, but they are 
not so simple to do correctly and they work with varying degrees of 
success.  Ask in one of the hardware groups and people will tell you 
more about them.

I can't say why GA left an oscillator off the GA144... I expect it was 
because Chuck doesn't think you need oscillators on an async chip... but 
in reality the applications are often not async and require hard clocking.

>> Why would you want to do polling or use interrupts in a conventional
>> MCU?  They all work at much lower power if you put them in stop state
>
> I think circuits like watches usually just run the processor at ultra
> low frequency (32 khz) rather than messing with fancy power control.

"Fancy" power control?  What is that?  Stopping the processor with a 
halt instruction is not exactly rocket science.  Why do you insist on 
making some simple things sound complex?  Why would you clock the chip 
running NOPs when you can save the power?

On the GA144 the processor runs full tilt until it reads or writes an 
I/O port.  It then stops until the condition is satisfied, the read or 
write completes and the processor moves on.  While waiting it is at 
"static" power level.  Each processor is independent.  Not complex - 
rather - very simple!

>> See, you *don't* understand the GA144.  Splitting the code across
>> cores is not a *requirement*, it is a *feature*!!!
>
> It's obvious from the examples that it slows down development
> enormously.  It would be much easier on Bernd's b16, which supports more
> code space than the F18.  He has said that typical b16 programs are
> 1k-2k which is much more reasonable than 64 words.

No, that is *not* obvious to me.  You continue to make the same 
assumptions and are not paying any attention to what I am writing. 
There is no point in continuing the conversation if you don't want to 
learn anything about the GA144.

>> This makes the code simple in the same way it is simple in an FPGA.
>> Imagine doing this in an FPGA. You would have an input counter ...
>
> How much FPGA resources are you going to end up using once all the stuff
> is there?  How much of the placement and routing will be automatically
> done by the HDL compiler, that you'll have to do by hand on the GA144?
> How much time is that going to take you?

Obviously you don't understand FPGAs any more than you do the GA144. 
Yes, place and route on an FPGA is complex and so is done by the tools. 
  Place and route of 144 elements is not so hard and so is done by hand. 
  Big woop!  The time is minimal.

>> ... outputs to another node which calculates the day, week, month and
>> year.  None of these are complex tasks and would fit easily in the
>> available node memory.  The aggregate time is passed on to the alarm
>> node which deals with handling alarm operation and the display node
>> with handles formatting the data for the LCD. ...
>
> Why don't you come up with a seat-of-the-pants time estimate of how long
> it will take you to place and route all these nodes (never mind
> implementation of the actual algorithms).  I'd be interested to know how
> that compares to the conventional approach where zero time is spent on
> that.

Place and route would be less than 5 minutes after I finish the 
coding... if that.

>> Another node is the "UI" which ... sends messages to all of these
>> nodes to set the current time.
>
> How is it even going to send those messages, given the number of nodes
> involved?  It's not an FPGA where there's a ton of routing resources at
> the disposal of the HDL compiler, and you can just say what signal is
> supposed to go where.  Routing on the GA144 is very limited and you have
> to program it explicitly in software (wire nodes etc).  Just
> communicating a button press from one node to another is potentially
> hours or days of mucking with code.
>
> Then there's the issue of inevitable rework.  You got the UI coded and
> fitting in 2 nodes?  Great, let's test it--oh no!  You better add some
> debouncing, which is going to take another node, which will mean moving
> all the other stuff around, and re-doing the routing, yada yada.  The
> customer wants to handle multiple time zones?  Same adventure again!
> Where in an MCU you'd just add a little more code to watch the buttons
> settle or implement the new feature.

Again you want to make this complex, but it is not.  You can continue to 
criticise the GA144 or you can understand it.  Pick one...

>> If I had the time I would code this up for you, but I'm busy with work
>> for a few more weeks.
>
> It will be interesting to see the code.  I won't even call for a
> complete implementation; a reasonable breakdown and estimate of the
> development time will probably be enlightening in its own right.
>
> By the way I don't think any serious amount of multi-tasking is needed
> in the conventional approach.  There'd just be an event loop that checks
> for RTC level changes and button presses.

Yes, that is probably true.  That's why I said you only need to deal 
with the Halt waiting for the 1 kHz input.

>> Look, I understand where you are coming from.  I have a different
>> perspective because I do FPGA work which always deals with multiple
>> processing elements.  This means I already have the development model
>> in my head.
>
> I've never programmed an FPGA (I want to sometime) but I've looked at
> the b16 Verilog code and think I get the idea.  Verilog looks much
> easier to me than programming the GA144.  It operates at a much higher
> level.  Even still, if programming FPGA's were so easy, we'd be using
> them instead of regular CPU's a lot more of the time.

If you try an HDL, no matter which one, just remember that you aren't 
programming a sequential processor.  You are describing hardware.  You 
may get something to work, but it can easily be inefficient and cumbersome.

Actually FPGAs *are* easy.  Again you just need to learn little 
grasshopper.  :)

-- 

Rick

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-24 11:02 +0200
  Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-24 05:54 -0700
    Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-25 10:51 +0200
      Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-25 02:29 -0700
        Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-25 14:06 +0200
          Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-25 10:34 -0700
            Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-26 11:03 +0200
              Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-26 22:18 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-27 12:09 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-06-27 11:15 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-27 09:55 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-06-27 15:02 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation visualforth@rocketmail.com - 2013-06-30 21:43 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-01 12:09 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-01 16:44 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-01 18:14 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-02 10:36 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Mark Wills <markrobertwills@yahoo.co.uk> - 2013-07-02 03:12 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-02 10:17 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-02 16:35 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-02 16:33 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-03 00:51 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-03 10:38 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-04 09:26 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 10:08 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-04 13:07 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 10:34 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-04 13:31 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 12:22 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 12:27 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-05 17:05 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-05 15:09 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-05 19:21 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-05 17:49 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-06 00:38 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-05 22:39 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-06 10:56 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-06 20:35 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-07 10:44 +0000
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-07 12:48 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-07 01:20 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-08 11:49 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-08 09:55 -0400
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Roberto Waltman <usenet@rwaltman.com> - 2013-07-06 12:48 -0400
          Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-08 14:47 +0200
            Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-08 09:37 -0700
            Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-07-09 11:32 +0000
              Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-09 14:27 +0200
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Bill Richards <billrich@gmx.com> - 2013-07-09 13:41 +0000
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-09 09:23 -0500
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-10 02:27 +0000
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Bill Richards <billrich@gmx.com> - 2013-07-10 07:34 +0000
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-10 03:18 -0500
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-10 01:43 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Brad Eckert <hwfwguy@gmail.com> - 2013-07-16 08:31 -0700
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-10 03:02 -0500
                Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-07-09 15:14 +0000
      Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation visualforth@rocketmail.com - 2013-07-15 12:27 -0700
        Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-16 11:52 +0200

csiph-web