User:SadEagle: Difference between revisions

From KDE TechBase
Line 15: Line 15:
* Idea: have a template for activation in FunctionImp, and then just memcpy, minus the params, on startup
* Idea: have a template for activation in FunctionImp, and then just memcpy, minus the params, on startup
** still need to setup functions separately, though.
** still need to setup functions separately, though.
** seems slower, actually
* Idea, part 2: use the above to setup immediates in the same place as registers. This can simplify the IR a lot and shrink the loop considerably.  
* Idea, part 2: use the above to setup immediates in the same place as registers. This can simplify the IR a lot and shrink the loop considerably.  
Also means there is no longer architecture differences in 32-bit and 64-bit needs at the IR level, and the IR gets smaller.
Also means there is no longer architecture differences in 32-bit and 64-bit needs at the IR level, and the IR gets smaller.
Line 20: Line 21:
* Alternative/conflict with below: if using a single stack for parameter passing/direct calls, we want to always do stack allocation and then do a deferred tearoff when needed --- this may actually be visible based on refcount  
* Alternative/conflict with below: if using a single stack for parameter passing/direct calls, we want to always do stack allocation and then do a deferred tearoff when needed --- this may actually be visible based on refcount  
of the scope chain, except when manually done.  
of the scope chain, except when manually done.  
* Do segmented/nonmoveable stack allocation --- just have a list of pieces, and work on them one at a time. Older ones can be recycled.
** That's actually done, but I am not sure of how to best combine it with other stuff
* Do deferred tearoffs. These mean we never have to refetch the locals array.
* Do segmented/nonmoveable stack allocation --- just have a list of pieces, and work on them one at a time. Older ones can be recycled. This means we never have to refetch the locals array.Also avoids the WARNING WARNING WARNING part.  
And they're easy! Also avoids the WARNING WARNING WARNING part. Well, if done with above.
* <s>Do deferred tearoffs. </s>
* eval operator/eval tearoffs
* eval operator/eval tearoffs
** tearoffs done.
** tearoffs done.

Revision as of 02:43, 6 June 2008

Misc stuff

KJS and KJS/Frostbyte

  • Value for global code, used in domts at least
    • Regression SunSpider?
    • Performance eval?
  • return-within-finally
    • Needs testing.
  • Debugger, again
    • Breakpoints done, but exceptions are trickier, since need Node
  • Unbreak CPU guard.
  • Idea: have a template for activation in FunctionImp, and then just memcpy, minus the params, on startup
    • still need to setup functions separately, though.
    • seems slower, actually
  • Idea, part 2: use the above to setup immediates in the same place as registers. This can simplify the IR a lot and shrink the loop considerably.

Also means there is no longer architecture differences in 32-bit and 64-bit needs at the IR level, and the IR gets smaller.

  • BUG: need to flush lazy local copies at function call (or do I do it already?)
  • Alternative/conflict with below: if using a single stack for parameter passing/direct calls, we want to always do stack allocation and then do a deferred tearoff when needed --- this may actually be visible based on refcount

of the scope chain, except when manually done.

    • That's actually done, but I am not sure of how to best combine it with other stuff
  • Do segmented/nonmoveable stack allocation --- just have a list of pieces, and work on them one at a time. Older ones can be recycled. This means we never have to refetch the locals array.Also avoids the WARNING WARNING WARNING part.
  • Do deferred tearoffs.
  • eval operator/eval tearoffs
    • tearoffs done.
    • With eval operator, if I keep track of lexical depth, may be
  able to directly route to global object, etc. Needs thought.
  • Easy one: custom StringImp::toString that takes care of object and prototype checking, etc. to avoid the extra lookup.
  • const
  • obscure sequencing thing
    • seems like an another regression on the TC though --- exception precision?
  • merge in the API, etc., from trunk
  • Do the List performance changes
  • Do IR dialectes for 32- and 64-bit -- e.g. PointerCell
    • Also probably double-allocator for 32-bit.
  • Do a review pass over API to make sure not BC leaks.
  • Solaris stack support for ade
  • Check bug #108538
  • Double-check global handling, synchronize with JSC
  • Consider using packed immediate/register bits. The key observation is that locals are read from an array, too, so we could do something like:
  arg0 = argsType[(fullOp >> 16) & 1][offsetVal];
  • Crazy idea: when going to proper CFG construction, do we even have to linearize?

KHTML - Short-term stuff

  • bug #162745 -- for CSS, we need to strip whitespace from URLs. Ditto for object, I'd think. Perhaps completeURL should do it.
  • For objects, empty URLs should probably embed still -- but when? CompleteURL on empty seems like a culprit for the self-embed bugs.
  • Inherit params
  • bug #161196 --- option value --- should be super-quick
  • JS Redirects
  • Iframe stuff
  • Fix the paranoia affecting(?) flickr(?) upload bug #126974
  • The XHTML parser mode
  • Check the XML parser -- QXML workaround might not be needed, weird whitespace handling and recovery stuff
  • Check the implicit node stuff. Only the form one seems correct to me, and that can be done w/o wasting a bit at top-level.
  • the libthai thing
  • bug #104358
  • XHR:
  • bug #103250 --- KWallet and pages with textareas.

khtmlImLoad

  • Allan's foreign loader patch
  • Scale animation provider for GIF --- bug #162614
  • Animation stoping
  • Better pre-blend cache?
  • FredrikH performance goodness?

KHTML - Long term stuff

Other long term stuff

  • Async loading of nspluginviewer somehow?
Retrieved from "https://techbase.kde.org/index.php?title=User:SadEagle&oldid=27800"