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 app
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, 147
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 overflow_add_
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 +++
target/arc/oper
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 a/tests/acc
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 Zissulescu
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 check_defin
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 remov
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 ge
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 i
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:
+DEFINE_PROP_BOOL("byte-order", ARCCPU, cfg.byte_order, false),
"byte-order" makes no sense as a bool.
"little-endian" or "big-endian" would.
+info->endian = BFD_ENDIAN_LITTLE;
Not using the setting?
+/*-*-indent-tabs-mode:nil;t
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 w
On 1/15/21 11:48 AM, Cupertino Miranda wrote:
>> In the case of enter or leave, this is one load/store plus one addition,
>> followed by a branch. All of which is encoded as fields in the instruction.
>> Extremely simple.
>
> So your recommendation is leave the conditional exception triggering of
On 1/15/21 11:28 AM, Shahab Vahedi wrote:
>>> +cpu_stl_data(env, tmp_sp, CPU_FP(env));
>>> +}
>>
>> And what if these stores raise an exception? I doubt you're going to get an
>> exception at the correct pc.
>
> I've added a few bad-weather test cases [1] and they work as expected. In
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 s
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 mirror
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 b
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 generating
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, cp
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 "Di
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 i
o see that
an aarch64 defconfig still build setup-irq.o with the patch applied.
The intention is that this patch doesn't change the behavior of any
build.
Signed-off-by: Palmer Dabbelt
Reviewed-by: James Hogan
---
arch/alpha/Kconfig | 1 +
Acked-by: Richard Hend
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 seg
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. This
32 matches
Mail list logo