public inbox for ~johnnyrichard/olang-devel@lists.sr.ht
 help / color / mirror / code / Atom feed
From: Johnny Richard <johnny@johnnyrichard.com>
To: Carlos Maniero <carlos@maniero.me>
Cc: ~johnnyrichard/olang-devel@lists.sr.ht
Subject: Re: [PATCH olang 5/5] codegen: perform mov instructions based on variable type
Date: Sat, 21 Sep 2024 21:17:55 +0200	[thread overview]
Message-ID: <dxh3ahdyr3hilf6ptfifmh6jaowkuu27h4m3kbz3hm5co2p47i@i3dg6mvj7hqi> (raw)
In-Reply-To: <20240921082437.396691-6-carlos@maniero.me>

On Sat, Sep 21, 2024 at 08:25:03AM GMT, Carlos Maniero wrote:
> There are two function that was introduced to performe the translations
> bellow:
> 
> type | type_to_bytes | bytes_to_rax
> -----------------------------------
>   u8 | 1             | ah
>  u16 | 2             | ax
>  u32 | 4             | eax
>  u64 | 8             | rax
> 
> I opted to create *bytes_to_rax* instead of *type_to_rax* mainly because
> we may use the same function to mov literals once we extend the literals
> as well (We say that all literals are u32 but we actually handle them as
> u64 on codegen).

Yeah, you are very right here.  I always mess with bytes sizes LOL.

> diff --git a/src/checker.c b/src/checker.c
> index f5068e0..3a78a59 100644
> --- a/src/checker.c
> +++ b/src/checker.c
> @@ -133,11 +133,26 @@ populate_scope(checker_t *checker, scope_t *scope, ast_node_t *ast)
>  static void
>  evaluate_type(type_t *type)
>  {
> +    if (string_view_eq_to_cstr(type->id, "u8")) {
> +        type->kind = TYPE_PRIMITIVE;
> +        type->as_primitive = TYPE_U8;
> +        return;
> +    }
> +    if (string_view_eq_to_cstr(type->id, "u16")) {
> +        type->kind = TYPE_PRIMITIVE;
> +        type->as_primitive = TYPE_U16;
> +        return;
> +    }
>      if (string_view_eq_to_cstr(type->id, "u32")) {
>          type->kind = TYPE_PRIMITIVE;
>          type->as_primitive = TYPE_U32;
>          return;
>      }
> +    if (string_view_eq_to_cstr(type->id, "u64")) {
> +        type->kind = TYPE_PRIMITIVE;
> +        type->as_primitive = TYPE_U64;
> +        return;
> +    }
>  
>      type->kind = TYPE_USER_DEFINED;
>  }

Is "as_primitive" property used only for calculate the size in bytes or
you see any other need in the future?

> diff --git a/src/codegen_linux_x86_64.c b/src/codegen_linux_x86_64.c
> index 415c81b..fa2a082 100644
> --- a/src/codegen_linux_x86_64.c
> +++ b/src/codegen_linux_x86_64.c
> @@ -38,6 +38,12 @@ codegen_linux_x86_64_emit_function(codegen_x86_64_t *codegen, ast_fn_definition_
>  static size_t
>  type_to_bytes(type_t *type);
>  
> +static char *
> +bytes_to_mov(size_t bytes);

Is this necessary?  I mean, isn't GAS smart enough to pick the right mov
instruction based on register size?

If we have to pick the right size mov explicitly, what do you think
about renaming it to **get_mov_inst_for(size_t)** or something alike to
express better the intention?

> +static char *
> +bytes_to_rax(size_t bytes);

This is similar to MOV instruction above, I was thinking about naming it
to **get_accumulator_reg_for(size_t)** or something else like it.  What
do you think?  The current name uses the 64bit version of the
accumulator register.

> +
>  void
>  codegen_linux_x86_64_init(codegen_x86_64_t *codegen, arena_t *arena, FILE *out)
>  {
> @@ -474,7 +502,7 @@ calculate_fn_local_size(scope_t *scope)
>  static void
>  codegen_linux_x86_64_emit_function(codegen_x86_64_t *codegen, ast_fn_definition_t *fn)
>  {
> -    codegen->base_offset = 0;
> +    codegen->base_offset = 8;

Nicely spotted!

>      ast_node_t *block_node = fn->block;
>      fprintf(codegen->out, "" SV_FMT ":\n", SV_ARG(fn->identifier));
>  

  parent reply	other threads:[~2024-09-21 19:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-21  8:24 [PATCH olang 0/5] extend unsined integers types (u8, u16, u64) Carlos Maniero
2024-09-21  8:24 ` [PATCH olang 1/5] parser: replace type enum to an struction string id representation Carlos Maniero
2024-09-21 17:59   ` Johnny Richard
2024-09-21  8:24 ` [PATCH olang 2/5] checker: scope: populate symbol's type Carlos Maniero
2024-09-21 18:47   ` Johnny Richard
2024-09-21 21:23     ` Carlos Maniero
2024-09-22 13:46       ` Johnny Richard
2024-09-21  8:24 ` [PATCH olang 3/5] codegen: fix map simbol list type Carlos Maniero
2024-09-21 18:50   ` Johnny Richard
2024-09-21  8:25 ` [PATCH olang 4/5] codegen: calculate the variable offset based on symbol type Carlos Maniero
2024-09-21 18:56   ` Johnny Richard
2024-09-21  8:25 ` [PATCH olang 5/5] codegen: perform mov instructions based on variable type Carlos Maniero
2024-09-21  8:26   ` [olang/patches/.build.yml] build success builds.sr.ht
2024-09-21 19:17   ` Johnny Richard [this message]
2024-09-21 21:30     ` [PATCH olang 5/5] codegen: perform mov instructions based on variable type Carlos Maniero
2024-09-22 14:16 ` [PATCH olang 0/5] extend unsined integers types (u8, u16, u64) Johnny Richard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dxh3ahdyr3hilf6ptfifmh6jaowkuu27h4m3kbz3hm5co2p47i@i3dg6mvj7hqi \
    --to=johnny@johnnyrichard.com \
    --cc=carlos@maniero.me \
    --cc=~johnnyrichard/olang-devel@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.johnnyrichard.com/olang.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox