-
Notifications
You must be signed in to change notification settings - Fork 10
/
TODO
108 lines (83 loc) · 4.6 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
1010101010101010101010101010101010101010101010101010101010101010101010101010101
0101010101010101010101010101010101010101010101010101010101010101010101010101010
1 ___ ___ _ ______ 1
0 | \/ | (_) | _ \ Open Source Tools, 0
1 | . . | _____ ___ ___| | | |_____ __ Firmware, and HDL code for 1
0 | |\/| |/ _ \ \/ / |/ _ \ | | / _ \ \ / / the Moxie processor core. 0
1 | | | | (_) > <| | __/ |/ / __/\ V / 1
0 \_| |_/\___/_/\_\_|\___|___/ \___| \_/ http://moxielogic.org/blog 0
1 1
0101010101010101010101010101010101010101010101010101010101010101010101010101010
1010101010101010101010101010101010101010101010101010101010101010101010101010101
This is the living TO DO document. Let me know if you're interesting
in tackling any of these..
Anthony Green <[email protected]>
-------------------------------------------------------------------------------
* Building
-------------------------------------------------------------------------------
- Add sanity check for ncurses-devel and SDL-devel
- Figure out how to save build logs (tee output? maybe ant has a
convenient mechanism).
-------------------------------------------------------------------------------
* Documentation
-------------------------------------------------------------------------------
- Use publican to document moxie architecture.
-------------------------------------------------------------------------------
* Compiler
-------------------------------------------------------------------------------
- Fix loads so they zero extend. The following code...
unsigned short *ptr;
int foo()
{
return *ptr;
}
...currently emits...
foo:
ldi.l $r1, 16
lda.l $r0, ptr
ld.s $r0, ($r0)
ashl $r0, $r1
lshr $r0, $r1
ret
The compiler should know that certain operations zero extend, so it doesn't have to
do that shifting hack.
- Consider sign extended versions of memory load operations.
- Shorten load/store offsets to 16-bits. They are currently 32-bits,
but for all of the benchmarks I’ve looked at the upper 16-bits are
always 0×0000 or 0xffff. If the compiler ever really wants to use
an offset > 16-bits, it should revert to computing the target
address in registers. I don’t expect that much code would require
this.
- Introduce shift instructions with immediate operands. There’s
plenty of opcode space for us to add 16-bit shift instructions that
include a 5-bit immediate shift value (so we can shift up to 32-bits
in either direction). Right now we load a 32-bit immediate shift value
into a register which burns that register as well as wastes 32-bits of
code space per shift.
- Get the compiler to generate 16-bit immediate loads. All
immediates are 32-bits right now, but the vast majority of these
constants are < 16 bits long.
- Push/pop multiple registers to the stack with one
instruction. Although we have 16-registers, the ABI doesn’t have us
pushing all 16 to the stack on function entry. We should be able to
have a single 16-bit instruction that pushes/pops all of the relevant
registers in one go. The instruction would include a bitmap
identifying the registers we need to push/pop. ARM has something like
this. It stores progress in a special register so that it can resume
memory reads/writes after an interrupt.
- Many register rich ISAs include one register that is hardwired to
zero. We could try this to see if it makes a difference, but I doubt
it would be a win. Another idea would be to create a cmpz instruction
to compare a register to zero so we don’t have to burn a register for
this common operation. Maybe cmp1 might even make sense. This is easy
to measure.
-------------------------------------------------------------------------------
* uClinux Port
-------------------------------------------------------------------------------
- Design early boot / handoff from firmware. Here are some initial thoughts..
- The kernel should assume that pointer to a flattened device tree is in one of
the special registers. How would it get there?
1) gdb sim.. import a dts/dtb file into the sim and force it into the end or RAM,
then load a pointer to it into one of the special regsters.
2) qemu.. similarly, but we should load the dtb from a file (as a .o maybe?) whose
name is based on the board/SoC we're simulation (moxiesim, for instance)