Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: refine there primitives %obj_size, %obj_field, %obj_set_field #7020

Closed
vicuna opened this issue Oct 15, 2015 · 5 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Oct 15, 2015

Original bug ID: 7020
Reporter: @bobzhang
Assigned to: @chambart
Status: assigned (set by @mshinwell on 2016-12-08T16:00:25Z)
Resolution: open
Priority: normal
Severity: feature
Category: back end (clambda to assembly)
Monitored by: @gasche @diml

Bug description

Motivation: currently the compiler internally transform:
%obj_size -> Parraylength Pgenarray
%obj_field -> Parrayrefu Pgenarray
%obj_set_field -> Parrayrefsetu Pgenarray

This enforces that the runtime system to encode the object as an array, which is fine for single runtime system. For the javascript backend, it would be nice encode array as is (no extra tag for a better FFI)

Solution 1: introduce three primitives in lambda
Pobj_size, Pobj_field, Pobj_set_field

Solution 2: introduce three c stubs
caml_obj_field, caml_obj_set_field, caml_obj_field

In both cases, the javascript backend can tell the difference between objects and arrays, the current bytecode backend and native backend can work as it is. Thanks -- Hongbo

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @mshinwell

Pierre, maybe you can think about this

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 11, 2020
@mshinwell
Copy link
Contributor

mshinwell commented May 11, 2020

I'd like to leave this open, as it's shown up an issue I wasn't aware of, which has relevance to Flambda 2.0 (where we are trying to be more careful about the distinction between arrays and blocks).

@mshinwell mshinwell removed the Stale label May 11, 2020
@mshinwell mshinwell self-assigned this May 11, 2020
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 14, 2021
@gasche gasche removed the Stale label May 14, 2021
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants