On 6/9/21 2:58 AM, Cupertino Miranda wrote:
We started to do that and in the process we realize that the approach
would bring us yet another encoding language description to maintain.
Why would you be maintaining another description? Your approach below with the
simple recursive algorithm
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
+/*
+ * ADD
+ *Variables: @b, @c, @a
+ *Functions: getCCFlag, getFFlag, setZFlag, setNFlag, setCFlag, CarryADD,
+ * setVFlag, OverflowADD
+ * --- code ---
+ * {
+ * cc_flag = getCCFlag ();
+ * lb = @b;
+ * lc = @c;
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
From: Cupertino Miranda
---
target/arc/semfunc-helper.c |13 +
target/arc/semfunc-helper.h |31 +
target/arc/semfunc-v3.c | 14653 ++
target/arc/semfunc-v3.h |55 +
4 files changed,
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
+if(ctx->insn.limm & 0x8000)
+ ctx->insn.limm += 0x;
(1) bad braces, but
(2) use an unconditional cast to int32_t.
Qemu forces the compiler to use standard 2's compliment arithmetic. We don't
have to go
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
+uint64_t helper_carry_add_flag32(uint64_t dest, uint64_t b, uint64_t c) {
+return carry_add_flag(dest, b, c, 32);
+}
+
+target_ulong helper_overflow_add_flag32(target_ulong dest, target_ulong b,
target_ulong c) {
+return
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
From: Cupertino Miranda
---
disas/arc.c| 51 +-
target/arc/decoder-v3.c| 1547
target/arc/decoder-v3.h| 322
target/arc/flags-v3.def| 103 +++
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
From: Cupertino Miranda
Just an acceptance test with ARC Linux booting.
Signed-off-by: Cupertino Miranda
---
tests/acceptance/boot_linux_console.py | 55 ++
1 file changed, 55 insertions(+)
diff --git
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
From: Claudiu Zissulescu
The added tests verify basic instructions execution as well
as more advanced features such as zero overhead loops interrupt
system, memory management unit and memory protection unit.
Signed-off-by: Claudiu
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
diff --git a/configure b/configure
index 535e6a9269..80d993fac7 100755
--- a/configure
+++ b/configure
@@ -680,6 +680,8 @@ elif check_define __arm__ ; then
cpu="arm"
elif check_define __aarch64__ ; then
cpu="aarch64"
+elif
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
+void arc_gen_verifyCCFlag(const DisasCtxt *ctx, TCGv ret)
Why "verify"? I don't see anything that verifies here...
I'll note that this can be done better, if you expose the actual comparison
rather than a simple boolean. This could
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
From: Cupertino Miranda
TCG generator scripts for semfunc.c file.
Signed-off-by: Cupertino Miranda
---
My only comment here is: do we really want to re-write semfunc.c, as opposed to
read one input file and output another? I presume that
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
+/*
+ * Function to add boiler plate code for conditional execution.
+ * It will add tcg_gen codes only if there is a condition to
+ * be checked (ctx->insn.cc != 0).
+ * Remember to pair it with gen_cc_epilogue(ctx) macro.
+ */
+static void
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
From: Cupertino Miranda
Add the most generic parts of TCG constructions. It contains the
basic infrastructure for fundamental ARC features, such as
ZOL (zero overhead loops) and delay-slots.
Also includes hand crafted TCG for more intricate
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
+static inline target_ulong
+carry_add_flag(target_ulong dest, target_ulong b, target_ulong c, uint8_t size)
+{
+target_ulong t1, t2, t3;
+
+t1 = b & c;
+t2 = b & (~dest);
+t3 = c & (~dest);
+t1 = t1 | t2 | t3;
+return
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
+static long long int
+extract_uimm6_20(unsigned long long insn ATTRIBUTE_UNUSED,
global replace long long int with int64_t,
and unsigned long long int with uint64_t.
+{
+ unsigned value = 0;
+
+ value |= ((insn >> 6) & 0x003f) << 0;
+
On 4/5/21 7:31 AM, cupertinomira...@gmail.com wrote:
In order to simplify the review process, we have separated the patches
for ARCv3 from the previous emailed ARCv2 ones. Being the patches from
1 to 16 for ARCv2 and 17 to 27 for ARCv3.
How may one find the arcv3 documentation on the synopsis
On 1/15/21 7:11 AM, Cupertino Miranda wrote:
>> Similarly. I think that both of these could be implemented entirely in
>> translate, which is what
>>
>>> +bool restore_fp= u7 & 0x10; /* u[4] indicates if fp must be saved
>>> */
>>> +bool restore_blink = u7 & 0x20; /* u[5] indicates
On 1/15/21 7:11 AM, Cupertino Miranda wrote:
>> On 11/11/20 10:17 AM, cupertinomira...@gmail.com wrote:
>>> +/*
>>> + * The macro to add boiler plate code for conditional execution.
>>> + * It will add tcg_gen codes only if there is a condition to
>>> + * be checked (ctx->insn.cc != 0). This macro
On 1/15/21 7:11 AM, Cupertino Miranda wrote:
> As you know, we reused the code from binutils to implement the decoder.
> In that sense, we kindly request to allow us to do it through binutils
> development flow later on. We will change the tables in binutils
> and those changes will also be
On 12/3/20 10:54 AM, Cupertino Miranda wrote:
> Our generation tool has different levels of verbosity, expressing
> instruction semantics from a pattern level up to what it is shown in
> as comments, which is later converted to TCG format.
> For QEMU purposes I would say that input format should
On 12/2/20 6:55 AM, Cupertino Miranda wrote:
> I totally understand your concerns with generated code.
>
> To explain our decision, we have an internal database that we are able
> to describe the architecture and map encoding with hw semantics, and
> for the sake of saving us debug time
On 11/11/20 10:17 AM, cupertinomira...@gmail.com wrote:
> +case 0x09:
> +/* (N & V & !Z) | (!N & !V & !Z) */
This is xnor(N, V) & !Z, and since as you now know xnor = eqv, you can perform
this in just two steps.
tcg_gen_eqv_tl(ret, cpu_Nf, cpu_Vf);
tcg_gen_andc_tl(ret, ret,
On 11/11/20 10:17 AM, cupertinomira...@gmail.com wrote:
> +/*
> + * The macro to add boiler plate code for conditional execution.
> + * It will add tcg_gen codes only if there is a condition to
> + * be checked (ctx->insn.cc != 0). This macro assumes that there
> + * is a "ctx" variable of type
On 11/11/20 10:17 AM, cupertinomira...@gmail.com wrote:
> From: Cupertino Miranda
>
> Signed-off-by: Cupertino Miranda
> ---
> target/arc/extra_mapping.def | 40 ++
> target/arc/helper.c| 293 +
> target/arc/helper.h| 46 ++
> target/arc/op_helper.c
On 11/11/20 10:17 AM, cupertinomira...@gmail.com wrote:
> From: Claudiu Zissulescu
>
> Signed-off-by: Claudiu Zissulescu
> ---
> target/arc/opcodes.def | 19976 +++
> 1 file changed, 19976 insertions(+)
> create mode 100644 target/arc/opcodes.def
OMG. 20k
On 11/11/20 10:17 AM, cupertinomira...@gmail.com wrote:
> +enum arc_cpu_family {
> + ARC_OPCODE_NONE= 0,
> + ARC_OPCODE_DEFAULT = 1 << 0,
> + ARC_OPCODE_ARC600 = 1 << 1,
> + ARC_OPCODE_ARC700 = 1 << 2,
> + ARC_OPCODE_ARCv2EM = 1 << 3,
> + ARC_OPCODE_ARCv2HS = 1 << 4
> +};
Indentation
1 +
Acked-by: Richard Henderson <r...@twiddle.net>
r~
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On 03/14/2017 10:39 AM, Till Smejkal wrote:
Is this an indication that full virtual address spaces are useless? It
would seem like if you only use virtual address segments then you avoid all
of the problems with executing code, active stacks, and brk.
What do you mean with *virtual address
On 03/14/2017 08:14 AM, Till Smejkal wrote:
At the current state of the development, first class virtual address spaces
have one limitation, that we haven't been able to solve so far. The feature
allows, that different threads of the same process can execute in different
AS at the same time.
29 matches
Mail list logo
