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


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

Mecrisp-Stellaris technology preview

Started byMatthias Koch <matthias.koch@hot.uni-hannover.de>
First post2015-09-25 11:10 +0200
Last post2015-10-06 09:38 +0200
Articles 7 — 2 participants

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


Contents

  Mecrisp-Stellaris technology preview Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-09-25 11:10 +0200
    Re: Mecrisp-Stellaris technology preview Paul Rubin <no.email@nospam.invalid> - 2015-09-29 15:52 -0700
      Re: Mecrisp-Stellaris technology preview Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-09-30 13:56 +0200
    Re: Mecrisp-Stellaris technology preview Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-09-30 19:02 +0200
    Re: Mecrisp-Stellaris technology preview Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-10-05 12:04 +0200
      Re: Mecrisp-Stellaris technology preview Paul Rubin <no.email@nospam.invalid> - 2015-10-05 09:48 -0700
        Re: Mecrisp-Stellaris technology preview Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-10-06 09:38 +0200

#42187 — Mecrisp-Stellaris technology preview

FromMatthias Koch <matthias.koch@hot.uni-hannover.de>
Date2015-09-25 11:10 +0200
SubjectMecrisp-Stellaris technology preview
Message-ID<mu3305$6fd$1@newsserver.rrzn.uni-hannover.de>
I just released a preview of a new compiler design for Mecrisp-Stellaris:
mecrisp-stellaris-ra-0.1-experimental.tar.gz
on mecrisp.sourceforge.net

If everything is fine, it should look and feel like the mainstream Mecrisp-Stellaris,
but it tracks the three top stack elements and maps them to registers whenever possible.

For now, this is highly experimental and it needs some more fine tuning before it is
ready for the mainstream release. But all underlying infrastructure is in place now,
and it is time for a thorough testing run out in the wild. If you are curious,
just give my proof of concept a try, and tell me of your experience.

Having a stack model inside adds about 4 kb of code for doing
the optimisations, so this definitively will break the former 16 kb core size limit.
Therefore, to pay for its own weight, it will be available as an option only
for the chips with large Flash memory side by side with the small and well tested
current compiler.

At this moment, only Cortex M0 is supported, and there is exactly one target: KL25Z128.
You can flash the included binary to your Freedom board or 
emulate it with the included Thumbulator.

Matthias

Two examples:

: >gray ( u -- x ) dup 1 rshift xor ;  ok.
  ok.
see >gray
00007CD0: B500  push { lr }
00007CD2: 0873  lsrs r3 r6 #1
00007CD4: 405E  eors r6 r3
00007CD6: BD00  pop { pc }
 ok.


: bitexp ( u -- u )  ok.
  ok.
  \ Returns an integer value equivalent to  ok.
  \ the exponential. For numbers > 16,  ok.
  \ bitexp(x) approx = 2^(x/8 + 1)  ok.
  ok.
  \ B(E(x)) = x for 16 <= x <= 247.  ok.
  ok.
  dup 247 u>  \ Overflow ?  ok.
  if drop $F0000000  ok.
  else  ok.
  ok.
    dup 16 u<= if 1 rshift  ok.
               else  ok.
                 dup ( u u )  ok.
                 7 and 8 or ( u b )  ok.
                 swap ( b u )  ok.
                 3 rshift 2 - lshift  ok.
               then  ok.
  ok.
  then  ok.
  ok.
  1-foldable ;  ok.
  ok.
see bitexp
00007BFE: B500  push { lr }
00007C00: 2EF7  cmp r6 #F7
00007C02: D801  bhi 00007C08
00007C04: 2300  movs r3 #0
00007C06: E001  b 00007C0C
00007C08: 2300  movs r3 #0
00007C0A: 43DB  mvns r3 r3
00007C0C: 2B00  cmp r3 #0
00007C0E: D002  beq 00007C16
00007C10: 26F0  movs r6 #F0
00007C12: 0636  lsls r6 r6 #18
00007C14: E012  b 00007C3C
00007C16: 2E10  cmp r6 #10
00007C18: D802  bhi 00007C20
00007C1A: 2300  movs r3 #0
00007C1C: 43DB  mvns r3 r3
00007C1E: E000  b 00007C22
00007C20: 2300  movs r3 #0
00007C22: 2B00  cmp r3 #0
00007C24: D001  beq 00007C2A
00007C26: 0876  lsrs r6 r6 #1
00007C28: E008  b 00007C3C
00007C2A: 0033  lsls r3 r6 #0
00007C2C: 2007  movs r0 #7
00007C2E: 4003  ands r3 r0
00007C30: 2008  movs r0 #8
00007C32: 4303  orrs r3 r0
00007C34: 08F6  lsrs r6 r6 #3
00007C36: 3E02  subs r6 #2
00007C38: 40B3  lsls r3 r6
00007C3A: 461E  mov r6 r3
00007C3C: BD00  pop { pc }
 ok.

Note that it compiles bitexp without any data stack movements at all.

[toc] | [next] | [standalone]


#42258

FromPaul Rubin <no.email@nospam.invalid>
Date2015-09-29 15:52 -0700
Message-ID<87h9mcalf2.fsf@jester.gateway.sonic.net>
In reply to#42187
Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> If everything is fine, it should look and feel like the mainstream
> Mecrisp-Stellaris, but it tracks the three top stack elements and maps
> them to registers whenever possible.

This sounds really neat!  I'd be interested to know how much code
improvement results.  I also wonder, is it easier to track just 3
elements instead of an arbitrary number of them?  And what happens with
those registers across function calls, where the called function might
want to do something with those stack elements?  Thanks.

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


#42271

FromMatthias Koch <matthias.koch@hot.uni-hannover.de>
Date2015-09-30 13:56 +0200
Message-ID<mugikg$a8l$1@newsserver.rrzn.uni-hannover.de>
In reply to#42258
>> If everything is fine, it should look and feel like the mainstream
>> Mecrisp-Stellaris, but it tracks the three top stack elements and maps
>> them to registers whenever possible.
> 
> This sounds really neat!  I'd be interested to know how much code
> improvement results.  I also wonder, is it easier to track just 3
> elements instead of an arbitrary number of them?  And what happens with
> those registers across function calls, where the called function might
> want to do something with those stack elements?  Thanks.

Hi Paul,

wait a bit before you ask for how many code improvement results.
I am currently implementing more optimisation cases, and they
really help dropping generated code size. The first release
is rather intended for infrastructure testing. Expect the full
blown compiler to be ready in November.

I have chosen three elements because I have three registers
available in Mecrisp-Stellaris. It is hardwired now, but the idea itself
can handle as many registers/elements as you wish. If I should decide
to do this for MSP430 somewhen in future, then I would go for more.

Across function calls, the registers are written to stack to give
an uniform interface. The nature of Forth allows anything to happen,
so I cannot have optimisations across different definitions,
at least as long as I cannot buffer large amounts of pieces in RAM.
Remember that everything is written directly into flash !

Matthias

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


#42279

FromMatthias Koch <matthias.koch@hot.uni-hannover.de>
Date2015-09-30 19:02 +0200
Message-ID<muh4h3$fi2$1@newsserver.rrzn.uni-hannover.de>
In reply to#42187
Just a fresh snapshot of the compiler !
Many more optimisation cases are now included.

You can find the mecrisp-stellaris-ra-0.2-experimental.tar.gz package
on mecrisp.sourceforge.net

Matthias


: bitexp ( u -- u )  ok.
  ok.
  \ Returns an integer value equivalent to  ok.
  \ the exponential. For numbers > 16,  ok.
  \ bitexp(x) approx = 2^(x/8 + 1)  ok.
  ok.
  \ B(E(x)) = x for 16 <= x <= 247.  ok.
  ok.
  dup 247 u>  \ Overflow ?  ok.
  if drop $F0000000  ok.
  else  ok.
  ok.
    dup 16 u<= if 1 rshift  ok.
               else  ok.
                 dup ( u u )  ok.
                 7 and 8 or ( u b )  ok.
                 swap ( b u )  ok.
                 3 rshift 2 - lshift  ok.
               then  ok.
  ok.
  then  ok.
  ok.
  1-foldable ;  ok.
  ok.
see bitexp 
00007B8E: B500  push { lr }
00007B90: 2EF7  cmp r6 #F7
00007B92: D902  bls 00007B9A
00007B94: 26F0  movs r6 #F0
00007B96: 0636  lsls r6 r6 #18
00007B98: E00C  b 00007BB4
00007B9A: 2E10  cmp r6 #10
00007B9C: D801  bhi 00007BA2
00007B9E: 0876  lsrs r6 r6 #1
00007BA0: E008  b 00007BB4
00007BA2: 0033  lsls r3 r6 #0
00007BA4: 2007  movs r0 #7
00007BA6: 4003  ands r3 r0
00007BA8: 2008  movs r0 #8
00007BAA: 4303  orrs r3 r0
00007BAC: 08F6  lsrs r6 r6 #3
00007BAE: 3E02  subs r6 #2
00007BB0: 40B3  lsls r3 r6
00007BB2: 461E  mov r6 r3
00007BB4: BD00  pop { pc }
 ok.

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


#42372

FromMatthias Koch <matthias.koch@hot.uni-hannover.de>
Date2015-10-05 12:04 +0200
Message-ID<muthtv$94o$1@newsserver.rrzn.uni-hannover.de>
In reply to#42187
Now available for M3/M4, too !
Added new target in Mecrisp-Stellaris RA 0.4 experimental: LM4F120.

Matthias

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


#42377

FromPaul Rubin <no.email@nospam.invalid>
Date2015-10-05 09:48 -0700
Message-ID<8737xp8do5.fsf@jester.gateway.sonic.net>
In reply to#42372
Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> Now available for M3/M4, too !
> Added new target in Mecrisp-Stellaris RA 0.4 experimental: LM4F120.

Nice!  I've been thinking a little bit about porting it to ARM Linux
with the idea of being able to test Mecrisp code on a Linux board before
dealing with an embedded target, as an alternative to Thumbulator.  Do
you think that is crazy?

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


#42388

FromMatthias Koch <matthias.koch@hot.uni-hannover.de>
Date2015-10-06 09:38 +0200
Message-ID<muvtnk$dr$1@newsserver.rrzn.uni-hannover.de>
In reply to#42377
> Nice!  I've been thinking a little bit about porting it to ARM Linux
> with the idea of being able to test Mecrisp code on a Linux board before
> dealing with an embedded target, as an alternative to Thumbulator.  Do
> you think that is crazy?

Actually, this is already included in Mecrisp-Stellaris 2.1.4.
It should run on any ARM Linux or ARM Android with at least an ARM7 CPU.

Matthias

[toc] | [prev] | [standalone]


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


csiph-web