1211146 - IonMonkey: MIPS32: Move MacroAssemblerMIPS to BaseMacroAssemblerMIPS

Status: RESOLVED INVALID

(Core :: JavaScript Engine: JIT, defect)

Description

[hev [:hev]]

TODO:
* Split MacroAssemblerMIPS to new files(BaseMacroAssembler-mips32).
* Rename MacroAssemblerMIPS to BaseMacroAssemblerMIPS.
* Rename MacroAssemblerMIPSCompat to MacroAssemblerMIPS.

Class hierachy and files:
Assembler  <-  BaseMacroAssemblerMIPS  <-  MacroAssemblerMIPS
               (aka MacroAssemblerMIPS)    (aka MacroAssemblerMIPSCompat)
               (BaseMacroAssembler-mips32) (MacroAssembler-mips32)

Move the MacroAssemblerMIPS to new files, it's easier how split MacroAssembler-mips32 to mips-shared. File dependencies is clearly:
Assembler-mips32.h <- BaseMacroAssembler-mips-shared.h <- BaseMacroAssembler-mips32.h <- MacroAssembler-mips-shared.h <- MacroAssembler-mips32.h

Comment 1

[hev [:hev]]

Attachment: 0001-IonMonkey-MIPS32-Move-MacroAssemblerMIPS-to-BaseMacr.patch

Generated by "git format-patch -M -C". Thanks!

Comment 2

[hev [:hev]]

Attachment: 0001-IonMonkey-MIPS32-Move-MacroAssemblerMIPS-to-BaseMacr.patch

Generated by "git format-patch -C10", looks it's easier than "-C -M".

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Heiher [:hev] from comment #0)
> TODO:
> * Split MacroAssemblerMIPS to new files(BaseMacroAssembler-mips32).

Honestly, even if this might sounds silly, I highly prefer to have one consistent way of handling macro assembler across architectures than have 6 different solutions to deal with when we are getting rid of this problem.

Please follow the same scheme as other architectures, even if this implies that you have to duplicate code.  We should address this issue on all architectures at once.

Comment 4

[hev [:hev]]

(In reply to Nicolas B. Pierron [:nbp] from comment #3)
> (In reply to Heiher [:hev] from comment #0)
> > TODO:
> > * Split MacroAssemblerMIPS to new files(BaseMacroAssembler-mips32).
> 
> Honestly, even if this might sounds silly, I highly prefer to have one
> consistent way of handling macro assembler across architectures than have 6
> different solutions to deal with when we are getting rid of this problem.
> 
> Please follow the same scheme as other architectures, even if this implies
> that you have to duplicate code.  We should address this issue on all
> architectures at once.

I got it. ^_^