Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote: > > That's a lot of typos in that patch... I wonder why the buildbot hasn't > > complained about this. Thanks for fixing this up! I'm going to fold this > > into the original to avoid the breakage. > > Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig. I've never got results. Which is annoying, as debian doesn't ship an ia64 cross toolchain either, and I can't find any pre-built one that works for me. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Christoph! On 12/2/20 9:43 AM, Christoph Hellwig wrote: > On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote: >>> That's a lot of typos in that patch... I wonder why the buildbot hasn't >>> complained about this. Thanks for fixing this up! I'm going to fold this >>> into the original to avoid the breakage. >> >> Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig. > > I've never got results. Which is annoying, as debian doesn't ship an > ia64 cross toolchain either, and I can't find any pre-built one that > works for me. The ia64 toolchain available from kernel.org works for me for cross-building a kernel that boots on my RX2600. It's just not a fully-fledged toolchain due to the limitations with libunwind. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On Wed, Dec 02, 2020 at 09:45:24AM +0100, John Paul Adrian Glaubitz wrote: > > I've never got results. Which is annoying, as debian doesn't ship an > > ia64 cross toolchain either, and I can't find any pre-built one that > > works for me. > > The ia64 toolchain available from kernel.org works for me for cross-building > a kernel that boots on my RX2600. > > It's just not a fully-fledged toolchain due to the limitations with libunwind. Actually, you are right, I did manage to finally get that working a while ago. I think openrisc is the one where I failed to get anything to work at all now that I think of it. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On Wed, Dec 02, 2020 at 08:43:26AM +, Christoph Hellwig wrote: > On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote: > > > That's a lot of typos in that patch... I wonder why the buildbot hasn't > > > complained about this. Thanks for fixing this up! I'm going to fold this > > > into the original to avoid the breakage. > > > > Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig. > > I've never got results. Which is annoying, as debian doesn't ship an > ia64 cross toolchain either, and I can't find any pre-built one that > works for me. Arnd publishes a bunch of cross compilers here: https://mirrors.edge.kernel.org/pub/tools/crosstool/ -- Sincerely yours, Mike. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On Wed, Dec 02, 2020 at 10:46:28AM +0200, Mike Rapoport wrote: > On Wed, Dec 02, 2020 at 08:43:26AM +, Christoph Hellwig wrote: > > On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote: > > > > That's a lot of typos in that patch... I wonder why the buildbot hasn't > > > > complained about this. Thanks for fixing this up! I'm going to fold this > > > > into the original to avoid the breakage. > > > > > > Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig. > > > > I've never got results. Which is annoying, as debian doesn't ship an > > ia64 cross toolchain either, and I can't find any pre-built one that > > works for me. > > Arnd publishes a bunch of cross compilers here: > > https://mirrors.edge.kernel.org/pub/tools/crosstool/ This is my source for those architectures where debian doesn't ship cross compilers. I'm stuck with mostly gcc 7/8 so I'm glad to see there have been some major updates. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/15] arc: TCG instruction definitions
Hi Richard,
Thank you so much for your reviews.
I will start working on improving the code straight away to try to
minimize waiting times.
However lets just address the elephant in the room.
Indeed we have the TCG definitions being generated.
However we are very serious about wanting to upstream our port and we
will certainly maintain this code.
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 each and every
instruction, we use it to generate both the TCG and instruction
decoding tables that you have already reviewed.
This tool is not only used in QEmu but through all our tools code,
allowing us to cross validate the content of the database.
Considering our situation and current state of the port, what would
you think is a reasonable compromise?
Once again thanks for the reviews.
Best regards,
Cupertino
On Tue, Dec 1, 2020 at 11:09 PM Richard Henderson
wrote:
>
> 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, cpu_Zf);
>
> > +/* GE */
> > +case 0x0A:
> > +/* (N & V) | (!N & !V) */
>
> xnor(N, V)
>
> > +/* LT */
> > +case 0x0B:
> > +/* (N & !V) | (!N & V) */
>
> xor(N, V)
>
> > +/* LE */
> > +case 0x0C:
> > +/* Z | (N & !V) | (!N & V) */
>
> xor(N, V) | Z
>
> > +/* HI */
> > +case 0x0D:
> > +/* !C & !Z */
> > +tcg_gen_xori_tl(nC, cpu_Cf, 1);
> > +tcg_gen_xori_tl(nZ, cpu_Zf, 1);
> > +
> > +tcg_gen_and_tl(ret, nC, nZ);
>
> !A & !B -> !(A | B), so one fewer xor.
>
> > +/* PNZ */
> > +case 0x0F:
> > +/* !N & !Z */
>
> Likewise.
>
> > +void arc_gen_set_memory(DisasCtxt *ctx, TCGv vaddr, int size,
> > +TCGv src, bool sign_extend)
> > +{
> > +switch (size) {
> > +case 0x00:
> > +tcg_gen_qemu_st_tl(src, vaddr, MEMIDX, MO_UL);
> > +break;
>
> Surely you'd put all of this size+sign-extend mapping into a table and issue
> just one tcg_gen_qemu_st_tl.
>
> > +void arc_gen_get_memory(DisasCtxt *ctx, TCGv dest, TCGv vaddr,
> > +int size, bool sign_extend)
> > +{
>
> And re-use the same table here, it would appear.
>
> > +void arc_gen_no_further_loads_pending(DisasCtxt *ctx, TCGv ret)
> > +{
> > +tcg_gen_movi_tl(ret, 1);
> > +}
>
> Huh? A missing TODO, perhaps?
>
> > +extern bool enabled_interrupts;
>
> Race condition. What is a global variable doing being set by a translation
> thread?
>
>
> > +void
> > +arc_gen_execute_delayslot(DisasCtxt *ctx, TCGv bta, TCGv take_branch)
> > +{
> > +static int in_delay_slot = false;
>
> And another one. Surely these belong in DisasContext.
>
> > +
> > +assert(ctx->insn.limm_p == 0 && !in_delay_slot);
> > +
> > +if (ctx->insn.limm_p == 0 && !in_delay_slot) {
> > +in_delay_slot = true;
> > +uint32_t cpc = ctx->cpc;
> > +uint32_t pcl = ctx->pcl;
> > +insn_t insn = ctx->insn;
> > +
> > +ctx->cpc = ctx->npc;
> > +ctx->pcl = ctx->cpc & 0xfffc;
> > +
> > +++ctx->ds;
> > +
> > +TCGLabel *do_not_set_bta_and_de = gen_new_label();
> > +tcg_gen_brcondi_i32(TCG_COND_NE, take_branch, 1,
> > do_not_set_bta_and_de);
> > +/*
> > + * In case an exception should be raised during the execution
> > + * of delay slot, bta value is used to set erbta.
> > + */
> > +tcg_gen_mov_tl(cpu_bta, bta);
> > +/* We are in a delay slot */
> > +tcg_gen_mov_tl(cpu_DEf, take_branch);
> > +gen_set_label(do_not_set_bta_and_de);
> > +
> > +tcg_gen_movi_tl(cpu_is_delay_slot_instruction, 1);
> > +
> > +/* Set the pc to the next pc */
> > +tcg_gen_movi_tl(cpu_pc, ctx->npc);
> > +/* Necessary for the likely call to restore_state_to_opc() */
> > +tcg_gen_insn_start(ctx->npc);
>
> Wow, this looks wrong.
>
> It doesn't work with icount or single-stepping. You need to be able to begin
> a
> TB at any instruction, including a delay slot.
>
> You should have a look at some of the other targets that handle this, e.g.
> openrisc or sparc. Since you've got NPC already, for looping, sparc is
> probably the better match.
>
> There should be no reason why you'd need to emit insn_start outside of
> arc_tr_insn_start.
>
> > +void arc_gen_set_register(enum arc_registers reg, TCGv value)
> > +{
> > +switch (reg) {
> > +case R_SP:
> > +tcg_gen_mov_i32(cpu_sp, value);
> > +break;
> > +case R_STATUS32:
> > +gen_helper_set_status32(cpu_env, value);
>
> Lots of changes to status imply a significant change to process
