Documentation Errors

Forum for anything not suitable for the other forums.

Re: Documentation Errors

Postby timpart » Sun Jul 28, 2013 7:53 pm

Gravis wrote:
timpart wrote:Architecture Reference Manual I'm looking at The Adapteva website latest documentation has an out of date link to

you have your documents mixed up. here's the latest:

Epiphany Architecture Reference Manual -
Epiphany SDK Reference Manual - <-- i think you were looking at a slightly earlier version of this

No, not mixed up, my copy is dated 29th March on my hard drive.

This thread suggests there is one later than mine as well. Can't see any sign on github now but perhaps it is lurking in the ftp which still has the old versions?

Posts: 302
Joined: Mon Dec 17, 2012 3:25 am
Location: UK

Re: Documentation Errors

Postby LamsonNguyen » Mon Jul 29, 2013 2:29 am


page 22
-last sentence in rMesh section has an extra period
-the penultimate sentence in the xMesh section has a misplaced hyphen.

Hope I'm not being too pedantic with the laundry list of errors. :oops:
Posts: 138
Joined: Sun Dec 16, 2012 7:09 pm

Re: Documentation Errors

Postby EggBaconAndSpam » Mon Jul 29, 2013 2:49 pm

Shouldn't it be "ADD <RD>, <RN>, #IMM3" rather than "ADD <RD>, <RN>, #SIMM3"? (same goes for SUB and 11 bits)
I mean, adding a signed constant seems rather pointless, if subtracting is available.

ADD R2,R1,#-100 is shown as an example, so apparently we are indeed talking about signed values.
That would restrict the SIMM3 variant to [-4;3]

Also, FIX,FLOAT and FABS all state RM somewhere, though only 1 register is involved.
Posts: 32
Joined: Tue Jul 16, 2013 2:39 pm

Re: Documentation Errors

Postby Gravis » Mon Jul 29, 2013 6:38 pm

when is the new version of the documentation coming out? >_<
User avatar
Posts: 445
Joined: Mon Dec 17, 2012 3:27 am
Location: East coast USA.

Re: Documentation Errors

Postby Gravis » Tue Jul 30, 2013 4:55 pm

the LDR/STR (INDEX and PM-IMM) instructions list show only +/- when the 16-bit versions cannot do subtraction. just a little confusing if you are looking at the opcode table and looking up the instructions.

LDR<size> <RD>, [<RN>, +/-<RM>]

should be
LDR<size> <RD>, [<RN>, +<RM>]
LDR<size> <RD>, [<RN>, +/-<RM>]
User avatar
Posts: 445
Joined: Mon Dec 17, 2012 3:27 am
Location: East coast USA.

Re: Documentation Errors

Postby Gravis » Sun Aug 04, 2013 1:17 am

this is more of an lack of inclusion of data issue.

while i'm sure it's possible deduce using Table 22: Pipeline Stage Description, it would be nice if somewhere it explicitly said how many cycles a particular operation took. i realize multiple opcodes use the same mnemonic, so i'm not sure how that information would be arranged. perhaps an additional column on Table 38: Epiphany Instruction Decode Table?
User avatar
Posts: 445
Joined: Mon Dec 17, 2012 3:27 am
Location: East coast USA.

Re: Documentation Errors

Postby hewsmike » Mon Aug 12, 2013 5:22 am

This is not necessarily an error per se, wording and consistency really. Picky me :-)

Take, say, page 102 ( of architecture reference ) describing the LDR(DISPLACEMENT) instruction :

address= RN +/- IMM<<( log2(size/8)-1);

Now I've got the idea that one scales the displacement/offset as per the chosen data size ( BYTE, HALF, WORD, DOUBLE ), and that one appends either B/H/W/D as appropriate to the tail of the mnemonic ( hence LDRB/LDRH/LDRW/LDRD ).

However for that bit shift of the immediate operand to the left, the size parameter ( my red emphasis ) only makes sense if it represents the number of bits of the operand thus :

address= RN +/- IMM<<( log2(size/8));

Eg. page 52 gives <size> as being one of B,H,L,D but here we mean <size> is one of 8/16/32/64 .... have I got that right ?? ;)

[ Likewise for the other instructions using that construct ]

[ Also the example on page 102 mentions LDRS, and while we know that designates a "short" : would a short be a byte or a halfword ? ]

Cheers, Mike.

( edit ) My apologies if this has already been picked up, but I couldn't find that on searching ....
Posts: 85
Joined: Mon Dec 17, 2012 3:20 am

Re: Documentation Errors

Postby Gravis » Mon Aug 12, 2013 7:31 am

hewsmike wrote:would a short be a byte or a halfword ?

well it does say on page 50 that...
Byte, short, word, and double data types are supported by all load/store instruction formats. All
loads and stores must be aligned with respect to the data size being used. Short (16-bit) data
types must be aligned on 16-bit boundaries in memory, word (32-bit) data types must be aligned
on 32-bit boundaries, and double (64-bit) data types must be aligned on 64-bit boundaries.

but it really would be nice to have a page specifying the size of each type. i dont really think of a word as 32-bit, so an explicit declaration would be nice.
User avatar
Posts: 445
Joined: Mon Dec 17, 2012 3:27 am
Location: East coast USA.

Re: Documentation Errors

Postby mhonman » Sat Oct 26, 2013 10:55 pm

In the Architecture Reference Manual (the pre-release one with the secret stuff), and also the current "official" architecture reference, the section for the TRAP instruction has incorrect descriptions of the use of R0 for the Fstat and Stat sub-functions.

fstat takes a file descriptor (numeric fd) as argument while stat takes a file name.

BTW there are more functions that could be implemented - see libgloss_syscall.h - I'm starting to wonder how many of the others might be referenced in the C runtime library, but that's another topic for another day!

[Edit: Having now worked through epiphany-newlib/libgloss/epiphany there are two more syscall traps that are implemented -
gettimeofday (19) and link (21).

gettimeofday parameters
  • R0 - address of the struct timeval that will be populated by the call.
  • R1 - address of the struct timezone that will be populated by the call.
  • R3 - 19

link parameters (link creates a new hard link)
  • R0 - address of the old filename
  • R1 - address of the new filename
  • R3 - 21

also, the open syscall takes the following values that are not described in this table
  • R1 - flags
  • R2 - mode

I think it would be useful to also document in this section:

  • return values can be found in R0
  • the errno value after the call is found in R3

For these traps to serve any useful purpose, there must be support code in the host. This support is provided by the e-server for cores to which gdb has established a connection, but the standard SDK does not provide a handler for these traps.

At least that's what I think happens, based on the contents of the code and documentation!

BTW it may be possible to implement some more of these calls:
  • isatty - can be passed through to the host. But is there gdb support for it? If not, can the e-server fake the result rather than doing it in the C library?
  • getpid - as a first step, it could return the global coreid (or some function of coreid) as pid.
  • kill - since sending signals to other cores is possible, could this become a wrapper for that function?

end of edit]
Posts: 112
Joined: Thu Apr 25, 2013 2:22 pm

Re: Documentation Errors

Postby mhonman » Thu Nov 14, 2013 4:31 pm

More on the traps.

The architecture reference has a table of the "other" traps (i.e. other than syscall) as follows:

0-2: reserved
3: program exit indicator
4: indicates success
5: indicates assertion
6: reserved

As of esdk 5.13.07 (and corresponding to the current head on github), the following are implemented in libgloss/epiphany/epiphany-syscalls.c (but so far I haven't found any code that generates traps 4 and 5)

0: asm_write
1: asm_read
2: asm_open
3: asm_exit - is definitely used, and corresponds to documentation
6: asm_close - occurs in real-world programs, but is not documented.
Posts: 112
Joined: Thu Apr 25, 2013 2:22 pm


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 15 guests