Difference between revisions of "BEEBS"

From MAGEEC
Jump to: navigation, search
m (Release 3.0)
m (Branch Management - Add a table of current branches.)
Line 12: Line 12:
 
== Branch Management ==
 
== Branch Management ==
  
We currently have several branches on github, some of which are out of date.  This section will soon contain a list of the active / inactive branches, along with documentation of what each branch is for.
+
We currently have several branches on github, some of which are out of date.  The following table lists all the branches that currently exist, when they were last committed too, and whether the branch has been merged back into either <tt>master</tt> or <tt>beebsv2</tt>.
 +
 
 +
The <tt>beebsv2</tt> branch is where the current development effort for the 2.0 release is taking place.
 +
 
 +
{|
 +
! scope="row" | Branch Name || Time Since Last Commit || Merged?
 +
|-
 +
| analysis || 8 months ||
 +
|-
 +
| atxmega256a3buxpld || 5 months || Yes (beebsv2)
 +
|-
 +
| autotools || 10 months || Yes (beebsv2 & master)
 +
|-
 +
| beebsv2 || hours ||
 +
|-
 +
| dejagnu || 2 months ||
 +
|-
 +
| dejagnu2 || 4 weeks ||
 +
|-
 +
| dejagnu2-jeremy || 4 weeks ||
 +
|-
 +
| fdct-fix || 5 weeks || Yes (beebsv2)
 +
|-
 +
| jeremy || 8 months ||
 +
|-
 +
| jp || 13 days || Yes (beebsv2)
 +
|-
 +
| master || 7 months ||
 +
|-
 +
| neville || 7 months || Yes (beebsv2)
 +
|-
 +
| pic32mx250f128b || 5 months || Yes (beebsv2)
 +
|-
 +
| planglois || 9 weeks || Yes (beebsv2)
 +
|-
 +
| python || 2 months ||
 +
|-
 +
| sam4lxplained || 5 months || Yes (beebsv2)
 +
|-
 +
| self-verify || 12 months || Yes (beebsv2 & master)
 +
|-
 +
| sjh || 8 months ||
 +
|-
 +
| stevekerrison || 8 months ||
 +
|-
 +
|}
  
 
=== Creating New Branches ===
 
=== Creating New Branches ===

Revision as of 19:35, 4 August 2014

Introduction

BEEBS is the Bristol/Embecosm Embedded Benchmark Suite, there's a blog post discussing BEEBS here.

Downloading And Building

The code is available on github. Clone the github repository and read the README file for details on how to build.

Note: Currently most of the interesting development is being done on the beebsv2 branch, you might want to switch to this branch before trying to build.

Branch Management

We currently have several branches on github, some of which are out of date. The following table lists all the branches that currently exist, when they were last committed too, and whether the branch has been merged back into either master or beebsv2.

The beebsv2 branch is where the current development effort for the 2.0 release is taking place.

Branch Name Time Since Last Commit Merged?
analysis 8 months
atxmega256a3buxpld 5 months Yes (beebsv2)
autotools 10 months Yes (beebsv2 & master)
beebsv2 hours
dejagnu 2 months
dejagnu2 4 weeks
dejagnu2-jeremy 4 weeks
fdct-fix 5 weeks Yes (beebsv2)
jeremy 8 months
jp 13 days Yes (beebsv2)
master 7 months
neville 7 months Yes (beebsv2)
pic32mx250f128b 5 months Yes (beebsv2)
planglois 9 weeks Yes (beebsv2)
python 2 months
sam4lxplained 5 months Yes (beebsv2)
self-verify 12 months Yes (beebsv2 & master)
sjh 8 months
stevekerrison 8 months

Creating New Branches

In future new branches should only be created within the official BEEBS repository if the branch is likely to be of use to a typical BEEBS user. The main thread of active development will continue in the BEEBS repository, but random proto-typing development branches should be created within forks of the BEEBS repository.

Once a feature is ready for inclusion in the main BEEBS development branch then merge the branch, or create a pull request.

Release Planning

Release 2.0

Currently planned for release August/September 2014.

The issue tracking for version 2.0 is on github, everything with the v2.0 milestone label is currently schedules for release 2.0.

The high level goals for the 2.0 release are:

  1. Remove unhelpful brenchmarks. Some of the benchmarks compile away to practically nothing, these should be deleted.
  2. Ensure wherever possible a GPL header is in place.
  3. Ensure that as many of the tests as possible build on the supported targets. Any tests that don't build should be baked into the exclude lists for that target, a user should not have to figure out which tests are not suitable for a supported target.

Release 3.0

Currently planned for release sometime after version 2.0.

There's a milestone setup for this release on github any issues for this release can be tracked there.

The high level goals for this release are:

  1. Add support for running the tests...
    1. On a variety of target boards.
    2. Using different testing strategies, for example, measuring run time, energy used, size of compiled binary.
  2. [ MAYBE ] Have the tests self verify themselves.