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

Groups > comp.sys.raspberry-pi > #12724 > unrolled thread

Jazelle?

Back to article view | Back to comp.sys.raspberry-pi

Contents

  Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-18 10:50 +0100
    Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-19 20:25 -0400
      Re: Jazelle? The Natural Philosopher <tnp@invalid.invalid> - 2016-07-20 07:08 +0100
        Re: Jazelle? Paul <paul@pcserviceselectronics.co.uk> - 2016-07-20 08:54 +0100
          Re: Jazelle? The Natural Philosopher <tnp@invalid.invalid> - 2016-07-20 09:29 +0100
            Re: Jazelle? Gordon Henderson <gordon+usenet@drogon.net> - 2016-07-20 12:56 +0000
              Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 14:54 +0100
                Re: Jazelle? Folderol <general@musically.me.uk> - 2016-07-20 18:40 +0100
                  Re: Jazelle? The Natural Philosopher <tnp@invalid.invalid> - 2016-07-20 19:12 +0100
                    Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 15:17 -0400
                  Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 20:32 +0100
                    Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 15:37 -0400
                      CAN / LIN auto bus (was Jazelle?) jeffj@panix.com (Jeff Jonas) - 2016-07-20 17:53 -0400
                        Re: CAN / LIN auto bus (was Jazelle?) Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-20 22:28 +0000
                        Re: CAN / LIN auto bus (was Jazelle?) druck <news@druck.org.uk> - 2016-07-20 23:37 +0100
            Re: Jazelle? alister <alister.ware@ntlworld.com> - 2016-07-20 13:34 +0000
              Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 10:26 -0400
              Re: Jazelle? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-20 19:51 -0400
          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? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 14:49 +0100
                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? "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? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-07-22 19:20 +0300
                    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? 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? 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? Robert Riches <spamtrap42@jacob21819.net> - 2016-07-21 01:27 +0000
                Re: Jazelle? "A. Dumas" <alexandre@dumas.fr.invalid> - 2016-07-21 05:58 +0200
                  Re: Jazelle? colonel_hack@yahoo.com - 2016-07-21 16:29 -0700
                    Re: Jazelle? "A. Dumas" <alexandre@dumas.fr.invalid> - 2016-07-22 01:56 +0200
                      Re: Jazelle? colonel_hack@yahoo.com - 2016-07-22 14:04 -0700
                    Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-22 11:59 +0100
            Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 10:56 -0400
        Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 10:24 -0400
      Re: Jazelle? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2016-07-20 14:38 +0100
        Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 14:57 +0100
          Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 10:53 -0400

Page 1 of 3  [1] 2 3  Next page →

#12724 — Jazelle?

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.

[toc] | [next] | [standalone]

#12730

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.

-- 

Rick C

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

#12733

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 in these days of GB RAM who cares?


-- 
How fortunate for governments that the people they administer don't think.

Adolf Hitler

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

#12736

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 in these days of GB RAM who cares?

That's the Microsoft way of adding bloat on the baiss oh well we have
lots oif RAM si it does not matter

Software design constructs that understand how the underlying
mechanisms work and do what they need to do and no more causes less 
problems in the long run.

Also proper design means no "Oh dear need a faster CPU, because I
don't understand why my software is slow" mantras as well

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate

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

#12738

On 20/07/16 08:54, Paul wrote:
> 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 in these days of GB RAM who cares?
>
> That's the Microsoft way of adding bloat on the baiss oh well we have
> lots oif RAM si it does not matter
>
Well yes, but even so, down at microcontroller level, we are not 
normally operating with 2k of RAM!


> Software design constructs that understand how the underlying
> mechanisms work and do what they need to do and no more causes less
> problems in the long run.
>
No arguments there.

> Also proper design means no "Oh dear need a faster CPU, because I
> don't understand why my software is slow" mantras as well
>
Apocryphal story: Gary Kildall (of CP/M fame) as a student  holiday 
project rewrote a huge chunk of assembler....in FORTRAN. It was 10 times 
faster...

It not the language, its understanding how the code works.


-- 
“But what a weak barrier is truth when it stands in the way of an 
hypothesis!”

Mary Wollstonecraft

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

#12744

In article <nmncop$7v3$1@news.albasani.net>,
The Natural Philosopher  <tnp@invalid.invalid> wrote:
>On 20/07/16 08:54, Paul wrote:
>> 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 in these days of GB RAM who cares?
>>
>> That's the Microsoft way of adding bloat on the baiss oh well we have
>> lots oif RAM si it does not matter
>>
>Well yes, but even so, down at microcontroller level, we are not 
>normally operating with 2k of RAM!

Some of us still do... ATmegas with 2K RAM and 32K ROM (flash) are
very popular (e.g. Arduino) ... And I dread to think how many of them
(bigger and smaller) or PIC microcontrollers there are in a typical car
these days...

Or microwave oven, fridge, coffee maker, etc.

I did a nice little project with the Atmel m48p a while back - 4K flash,
512 bytes of RAM. Lovely litle thing. Runs of a coin cell for over
2 years...

Gordon

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

#12749

"Gordon Henderson" <gordon+usenet@drogon.net> wrote in message 
news:nmnsdf$26f$1@dont-email.me...
> Some of us still do... ATmegas with 2K RAM and 32K ROM (flash) are
> very popular (e.g. Arduino) ... And I dread to think how many of them
> (bigger and smaller) or PIC microcontrollers there are in a typical car
> these days...

Having worked on car systems (and railway brakes and signals) I
doubt very much the appearance of PICs in anything other
than CD players.

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

#12763

On Wed, 20 Jul 2016 14:54:21 +0100
"gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> wrote:

> "Gordon Henderson" <gordon+usenet@drogon.net> wrote in message 
> news:nmnsdf$26f$1@dont-email.me...
> > Some of us still do... ATmegas with 2K RAM and 32K ROM (flash) are
> > very popular (e.g. Arduino) ... And I dread to think how many of them
> > (bigger and smaller) or PIC microcontrollers there are in a typical car
> > these days...  
> 
> Having worked on car systems (and railway brakes and signals) I
> doubt very much the appearance of PICs in anything other
> than CD players.

Oh really?

So I was dreaming about the ones running print registration control retro-
fitted to several printing presses. Oh, and the eleven managing a
distributed silo control system in a plastics factory that runs 24/7.

I'll exclude the one that controls a production shift changeover, display and
information system, seeing as it cheats, and uses an external GPS module for
time & date.


-- 
W J G

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

#12764

On 20/07/16 18:40, Folderol wrote:
> On Wed, 20 Jul 2016 14:54:21 +0100
> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> wrote:
>
>> "Gordon Henderson" <gordon+usenet@drogon.net> wrote in message
>> news:nmnsdf$26f$1@dont-email.me...
>>> Some of us still do... ATmegas with 2K RAM and 32K ROM (flash) are
>>> very popular (e.g. Arduino) ... And I dread to think how many of them
>>> (bigger and smaller) or PIC microcontrollers there are in a typical car
>>> these days...
>>
>> Having worked on car systems (and railway brakes and signals) I
>> doubt very much the appearance of PICs in anything other
>> than CD players.
>
> Oh really?
>
> So I was dreaming about the ones running print registration control retro-
> fitted to several printing presses. Oh, and the eleven managing a
> distributed silo control system in a plastics factory that runs 24/7.
>
> I'll exclude the one that controls a production shift changeover, display and
> information system, seeing as it cheats, and uses an external GPS module for
> time & date.
>
>
ROFL

PIcs used everywhere. mate of mine is controlling specialised power 
supply for a scientific instrument. PIC does teh PWM to stabilise teh 
voltage

One in every digital camera too....


-- 
Future generations will wonder in bemused amazement that the early 
twenty-first century’s developed world went into hysterical panic over a 
globally average temperature increase of a few tenths of a degree, and, 
on the basis of gross exaggerations of highly uncertain computer 
projections combined into implausible chains of inference, proceeded to 
contemplate a rollback of the industrial age.

Richard Lindzen

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

#12765

On 7/20/2016 2:12 PM, The Natural Philosopher wrote:
> On 20/07/16 18:40, Folderol wrote:
>> On Wed, 20 Jul 2016 14:54:21 +0100
>> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> wrote:
>>
>>> "Gordon Henderson" <gordon+usenet@drogon.net> wrote in message
>>> news:nmnsdf$26f$1@dont-email.me...
>>>> Some of us still do... ATmegas with 2K RAM and 32K ROM (flash) are
>>>> very popular (e.g. Arduino) ... And I dread to think how many of them
>>>> (bigger and smaller) or PIC microcontrollers there are in a typical car
>>>> these days...
>>>
>>> Having worked on car systems (and railway brakes and signals) I
>>> doubt very much the appearance of PICs in anything other
>>> than CD players.
>>
>> Oh really?
>>
>> So I was dreaming about the ones running print registration control
>> retro-
>> fitted to several printing presses. Oh, and the eleven managing a
>> distributed silo control system in a plastics factory that runs 24/7.
>>
>> I'll exclude the one that controls a production shift changeover,
>> display and
>> information system, seeing as it cheats, and uses an external GPS
>> module for
>> time & date.
>>
>>
> ROFL
>
> PIcs used everywhere. mate of mine is controlling specialised power
> supply for a scientific instrument. PIC does teh PWM to stabilise teh
> voltage
>
> One in every digital camera too....

I have to assume the term "PIC" is being used incorrectly as a synonym 
for MCU.  PIC is a trade name and MCU is the correct term.  If you say 
PIC, I assume you mean the PIC line of MCUs.

-- 

Rick C

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

#12767

"Folderol" <general@musically.me.uk> wrote in message 
news:20160720184020.4195ed27@debian...
> On Wed, 20 Jul 2016 14:54:21 +0100
> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> wrote:
>> "Gordon Henderson" <gordon+usenet@drogon.net> wrote in message
>> news:nmnsdf$26f$1@dont-email.me...
>> > Some of us still do... ATmegas with 2K RAM and 32K ROM (flash) are
>> > very popular (e.g. Arduino) ... And I dread to think how many of them
>> > (bigger and smaller) or PIC microcontrollers there are in a typical car
>> > these days...
>> Having worked on car systems (and railway brakes and signals) I
>> doubt very much the appearance of PICs in anything other
>> than CD players.
> Oh really?
> So I was dreaming about the ones running print registration control retro-
> fitted to several printing presses. Oh, and the eleven managing a
> distributed silo control system in a plastics factory that runs 24/7.
> I'll exclude the one that controls a production shift changeover, display 
> and
> information system, seeing as it cheats, and uses an external GPS module 
> for
> time & date.

I'm sorry, but you seem to have misunderstood me and then shot off on a 
tangent.

By discussing the CD player I was referring to the only likely place in a 
car
that you'd find a PIC.

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

#12769

On 7/20/2016 3:32 PM, gareth G4SDW GQRP #3339 wrote:
> "Folderol" <general@musically.me.uk> wrote in message
> news:20160720184020.4195ed27@debian...
>> On Wed, 20 Jul 2016 14:54:21 +0100
>> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> wrote:
>>> "Gordon Henderson" <gordon+usenet@drogon.net> wrote in message
>>> news:nmnsdf$26f$1@dont-email.me...
>>>> Some of us still do... ATmegas with 2K RAM and 32K ROM (flash) are
>>>> very popular (e.g. Arduino) ... And I dread to think how many of them
>>>> (bigger and smaller) or PIC microcontrollers there are in a typical car
>>>> these days...
>>> Having worked on car systems (and railway brakes and signals) I
>>> doubt very much the appearance of PICs in anything other
>>> than CD players.
>> Oh really?
>> So I was dreaming about the ones running print registration control retro-
>> fitted to several printing presses. Oh, and the eleven managing a
>> distributed silo control system in a plastics factory that runs 24/7.
>> I'll exclude the one that controls a production shift changeover, display
>> and
>> information system, seeing as it cheats, and uses an external GPS module
>> for
>> time & date.
>
> I'm sorry, but you seem to have misunderstood me and then shot off on a
> tangent.
>
> By discussing the CD player I was referring to the only likely place in a
> car
> that you'd find a PIC.

Are you saying the single product line that is referred to by the 
trademark "PIC" or are you using PIC as a synonym for MCU?  If the 
former, so what?  If the latter, you are totally wrong.  There are 
dozens of MCUs in the typical auto including the engine controller which 
was in widespread use two decades ago.  Are you driving a 1956 MG or 
something?

-- 

Rick C

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

#12770 — CAN / LIN auto bus (was Jazelle?)

>>>>> And I dread to think how many of them
>>>>> (bigger and smaller) or PIC microcontrollers there are in a typical car

Let me try to turn this around:
most microcontrollers (Atmel AVR, Microchip PIC)
now have built-in CAN and LIN controllers.
Or they're retrofitted via I2C or SPI.

Does the presence of a CAN bus imply automotive, or is it used elsewhere?

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

#12771 — Re: CAN / LIN auto bus (was Jazelle?)

On Wed, 20 Jul 2016 17:53:36 -0400, Jeff Jonas wrote:

>>>>>> And I dread to think how many of them (bigger and smaller) or PIC
>>>>>> microcontrollers there are in a typical car
> 
> Let me try to turn this around:
> most microcontrollers (Atmel AVR, Microchip PIC)
> now have built-in CAN and LIN controllers.
> Or they're retrofitted via I2C or SPI.
> 
> Does the presence of a CAN bus imply automotive, or is it used
> elsewhere?

It started as a Bosch designed automotive bus (1983) that has since 
spread into industrial (SCADA) and aerospace applications. 

RaspberryPi and Arduino users can experiment with CAN-bus because there 
are RaspberryPi expansion cards and Arduino shields that support it.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#12772 — Re: CAN / LIN auto bus (was Jazelle?)

On 20/07/2016 22:53, Jeff Jonas wrote:
> Does the presence of a CAN bus imply automotive, or is it used elsewhere?

It's used for industrial control systems too.

In a previous company we used a whole stack of analogue and digital I/O 
modules connected via CAN bus to build a 3/4 Hawk fighter plane to train 
RAF ground crew. Instead of messy and quite dangerous high pressure 
hydraulics in conventional ground trainers (old or crashed aircraft) it 
used electronic actuators and optical sensors in the pipework.

http://www.pennantplc.co.uk/static/files/casestudies/case%20study_GenFly.pdf

Back at the turn of the millennium we were frying early Pentium 90/133s 
running the I/O control, hydraulic and electrical emulation systems, but 
we'd be using few Raspberry Pi's if we were doing it today.

---druck

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

#12745

On Wed, 20 Jul 2016 09:29:15 +0100, The Natural Philosopher wrote:

> On 20/07/16 08:54, Paul wrote:
>> 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 in these days of GB RAM who cares?
>>
>> That's the Microsoft way of adding bloat on the baiss oh well we have
>> lots oif RAM si it does not matter
>>
> Well yes, but even so, down at microcontroller level, we are not
> normally operating with 2k of RAM!
> 
Oh no
look at the verry common AMTel AVR series

ATTiny 2323	128 bytes
ATTiny 85	512 bytes

even the ATMega328 (as used in Arduino) only has 2k bytes.

I am pretty sure the figures for the Microchip PIC series are similar as 
are those for the 8051 

> 
>> Software design constructs that understand how the underlying
>> mechanisms work and do what they need to do and no more causes less
>> problems in the long run.
>>
> No arguments there.
> 
>> Also proper design means no "Oh dear need a faster CPU, because I don't
>> understand why my software is slow" mantras as well
>>
> Apocryphal story: Gary Kildall (of CP/M fame) as a student  holiday
> project rewrote a huge chunk of assembler....in FORTRAN. It was 10 times
> faster...
> 
> It not the language, its understanding how the code works.





-- 
Moderation in all things.
		-- Publius Terentius Afer [Terence]

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

#12752

On 7/20/2016 9:34 AM, alister wrote:
> On Wed, 20 Jul 2016 09:29:15 +0100, The Natural Philosopher wrote:
>
>> On 20/07/16 08:54, Paul wrote:
>>> 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 in these days of GB RAM who cares?
>>>
>>> That's the Microsoft way of adding bloat on the baiss oh well we have
>>> lots oif RAM si it does not matter
>>>
>> Well yes, but even so, down at microcontroller level, we are not
>> normally operating with 2k of RAM!
>>
> Oh no
> look at the verry common AMTel AVR series
>
> ATTiny 2323	128 bytes
> ATTiny 85	512 bytes
>
> even the ATMega328 (as used in Arduino) only has 2k bytes.
>
> I am pretty sure the figures for the Microchip PIC series are similar as
> are those for the 8051

Those are RAM figures where code is typically not stored.  Code is 
normally stored in Flash which all these devices have much more.  TNP 
was thinking in terms of the rPi which has no on chip Flash... or RAM 
for that matter.

-- 

Rick C

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

#12773

On Wed, 20 Jul 2016 13:34:23 GMT, alister <alister.ware@ntlworld.com>
declaimed the following:


>look at the verry common AMTel AVR series
>
>ATTiny 2323	128 bytes
>ATTiny 85	512 bytes
>
>even the ATMega328 (as used in Arduino) only has 2k bytes.
>
>I am pretty sure the figures for the Microchip PIC series are similar as 
>are those for the 8051 
>
	PIC16F676	1K instruction, 64 byte RAM (14 pin)
	PIC16F690 4K instruction, 256 byte RAM (20 pin)
	PIC16F877A 8K instruction, 368 byte RAM (40 pin)
	PIC18F2520 16K instruction, 1536 byte RAM (28 pin)

NOTE: instructions tend to be 12-bit for 16F series -- I don't recall if my
database is listing #instructions (meaning 1.5KB for the 676) or actual
bytes.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#12740

"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.

Interpreting another assembly language must be the height of nuttiness!

Consider the solution of the quadratic equation expressed in
a HLL ...

X = (-B + SQRT ( B**2 - 4*A*C))?2*A

... then consider what you have to do in Forth to achieve the same end.
of pushing variables onto the stack and manipulating that stack to
realise that Forth is, indeed, assembly language!

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

#12741

"gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>Consider the solution of the quadratic equation expressed in
>a HLL ...
>
>X = (-B + SQRT ( B**2 - 4*A*C))?2*A

Which HLL uses "?" as division operator that has lower priority than
"*"; actually, which HLL has a division operator with lower priority
than "*"?

Anyway, this way of computing one of the solutions for a quadratic
equation is bad because it introduces more numerical instability than
is coming from the problem itself.  Read more about how to do it
better in

<http://home.pipeline.com/~hbaker1/sigplannotices/sigcol05.pdf>
<http://home.pipeline.com/~hbaker1/sigplannotices/sigcol06.pdf>

>... then consider what you have to do in Forth to achieve the same end.
>of pushing variables onto the stack and manipulating that stack to
>realise that Forth is, indeed, assembly language!

Yes.  Forth has the benefits of assembly language (stability,
performance) as well as some of the benefits of higher-level languages
(in particular, portability), mitigating the drawbacks of assembly
language (non-portability) and higher-level languages (instability for
C, low performance for, e.g., Python).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.sys.raspberry-pi

csiph-web