current machineType INT * FLOAT* confuse people to associate UINT*.
the INT* is simlar with LLVM IR too
we reanme machineType INT* FLOAT* rename to I* and F*
issue: https://gitee.com/openharmony/ark_js_runtime/issues/I4SC94
Signed-off-by: songzhengchao <songzhengchao@huawei.com>
Change-Id: Ie188e07039cd9f26aed436ce96618ea4143fccd6
To ensure the high performance of container classes, TreeMap and
TreeSet is provided in ark.
Add test cases for TaggedTree.
Related issue
#I4PQ1G:add TreeMap and TreeSet
Change-Id: I5cda72d06a71380711374109a87e971af6a8c5b7
Signed-off-by: xliu <liuxin259@huawei.com>
current stub Word*** function sometime handle unsigned int or signed
int, we refactor name it uint** or int** whichi is more clear
issue: https://gitee.com/openharmony/ark_js_runtime/issues/I4SC94
Signed-off-by: songzhengchao <songzhengchao@huawei.com>
Change-Id: Ieb6e201d18c59fdd3fa7130b70389c54d619e3b2
Add VMNeedSuspension judge in CheckSafepoint and provide SuspendVM() ResumeVM() api in jsnapi to Suspend VM and Resume VM
Modify GetEcmaUncaughtException no longer clear exception and Add GetAndClearEcmaUncaughtException to get and clear exception
Issue I4SECM
Signed-off-by: scw <suchongwei@huawei.com>
Why
DFX use test in the use of hap, found that generate json file could not be chrome parsing
Description
Change the time stamp of the type of the variable, which can be stored subtle level
Change the code logic, which can identify fault frames and export right to json
On branch master
Your branch is up to date with 'origin/master'.
construct function and refactor stub call runtime offset which's relative with
arch framework
current stub call runtime writebarrier, writebarrier stub is conveient
to optimized by llvm pass
region class markingbitmap should be not nullptr, it's good way to
inilized on construct class other than lazy inilized
current stub get member offset of runtime class, need to modify multiple
places which is not coveient to maintance. stub call offset by GetOldToxxxOffset and
CheckLayout which is checked by compile phase
issue: https://gitee.com/openharmony/ark_js_runtime/issues/I4SC94
Change-Id: Iec087f07ca27ef95b20ff65ea8bb9408b5887d9c
Signed-off-by: songzhengchao <songzhengchao@huawei.com>
Description
There is conceptual confusion in the definition of delete in nativepoint. Modify it to avoid ambiguity
modify 'delete(buffer, data)' to delete(nativePointer, data).
Related issues
#I4SK2G: Modify the name of nativepointer
Signed-off-by: linxiang <linxiang8@huawei.com>
The current TypeCode is only used to represent the type of the MIR
and cannot represent the TS type data type. The type derivation
process needs to get the TS type information from the circuit ir.
Redefining the layout of TypeCode
issue:https://gitee.com/openharmony/ark_js_runtime/issues/I4SFHE
Signed-off-by: wanyanglan <wanyanglan1@huawei.com>
Change-Id: I53292db81712b84210114f9f92c44b6236c356af
ts aot should be a separate part that needs to generate the
corresponding file before executing xxx.abc and should not
depend on the execution of xxx.abc
issue:https://gitee.com/openharmony/ark_js_runtime/issues/I4RP3H
Signed-off-by: wanyanglan <wanyanglan1@huawei.com>
Change-Id: I4ed7d7ee5528dcb479e08486f332a48c16ea88d7
In the circuit ir bytecode are translated as JS_BYTECODE,
when printing do not know which bytecode is corresponding,
need to know the current translation of the circuit ir
corresponding to the bytecode is what
issue:https://gitee.com/openharmony/ark_js_runtime/issues/I4RP3H
Signed-off-by: wanyanglan <wanyanglan1@huawei.com>
Change-Id: I095f7d04c8511c70f6f2f3152db9ba058b2addba
ts aot bytecode to circuit ir does not yet support the conversion operation for the throw instruction
issue:https://gitee.com/openharmony/ark_js_runtime/issues/I4RP3H
Signed-off-by: wanyanglan <wanyanglan1@huawei.com>
Change-Id: I1c39ae74db6776f7b4086f380170afd5e4681f64
The current circuit ir is translated to llvm ir according to the type of opcode,
and depends on different platforms. circuit ir, as an intermediate state from MIR
to LLVM IR, only performs the conversion role and should not depend on different
platforms for different conversion operations.
The uniqueness of the opcode is removed, and the opcode is combined with a valuecode,
which indicates the uniqueness of each MIR.
issue: https://gitee.com/openharmony/ark_js_runtime/issues/I4RP3H
Signed-off-by: wanyanglan <wanyanglan1@huawei.com>
Change-Id: I2804e7ba9be58fcc4acf3d95a417224b7984018a
Separate bc to ir code logic from panda_file_translator to bytecode_circuit_builder
issue:https://gitee.com/openharmony/ark_js_runtime/issues/I4RP3H
Signed-off-by: xujie <xujie101@huawei.com>
Change-Id: I08e5b27f4f648ac66aec62c66662fcf4d89916dd
Implemented circuit ir builder based on the SSA information generated by
previous processes, according to the specification of circuit ir.
issue:https://gitee.com/openharmony/ark_js_runtime/issues/I4RP3H
Signed-off-by: Mingliang Zeng <zengmingliang1@huawei.com>
Change-Id: I23d4f88d2f5b8164e6f31f0d0092a1dcbc55d976
The conversion of bytecode to circuit ir involves building cfg at
the bytecode level and building circuit ir based on the information
stored in cfg.
issue: https://gitee.com/openharmony/ark_js_runtime/issues/I4RP3H
Signed-off-by: wanyanglan <wanyanglan1@huawei.com>
Change-Id: Ic384e6c9e4a456c9ff44f0789dd8e8826328e32d
