IRC channel logs

<stikonas>ekaitz: ok, I have a better version now

<stikonas>still not good though

<stikonas>breaks knight architecture

<oriansj>gtker: for byte based architectures the way to express signed 16bit values is @0x1234 but for unsigned 16bit values is $0x1234

<stikonas> https://paste.debian.net/1362951/

<oriansj>stikonas: it is ok to break knight architecture, I'll fix it later

<stikonas>well, it's still an ugly hack (this diff above)

<stikonas>but I guess our tokenizer is not very good with :

<oriansj>well originally I only supported : for goto labels

<stikonas>yeah...

<oriansj>as I could see a real need for goto in M2-Planet but not many other real uses

<oriansj>(of : )

<stikonas>maybe it would be cleaner to manually split ":token" into "token" followed by another token ":"

<stikonas>in process_switch

<stikonas>hmm

<oriansj>easy to do, just requires more logic to handle labels as they would no longer be prefixed by :

<stikonas>oh, knight is broken by gtker...

<stikonas>in the last commit

<stikonas>not by me...

<stikonas>or that might simply be me using old mescc-tools

<oriansj>knight can be sacrificed; I doubt anyone besides me was interested in making it real hardware.

<stikonas>no, this was simply me not having your latest changes

<stikonas>where you added support for %

<stikonas>anyway, I'll create a PR

<stikonas>then ekaitz can test it

<oriansj>stikonas: technically I added support for !@$%& to knight

<stikonas> https://github.com/oriansj/M2-Planet/pull/100

<stikonas>ekaitz: ^^

<stikonas>see if this helps?

<stikonas>at least make test works now

<stikonas>so shouldn't have broken much

<ekaitz>i'm still building with the numbers

<ekaitz>but will try

<ekaitz>stikonas: works for at least building it

<ekaitz>i didn't test yet if the resulting mes works

<stikonas>anyway, we can try to make a release tomorrow or on saturday then...

<stikonas>sounds like you would benefit a lot from new M2-Planet

<stikonas>ekaitz: have you looked at m2-planet changelog https://raw.githubusercontent.com/oriansj/M2-Planet/refs/heads/master/CHANGELOG.org ?

<stikonas>quite a few things since the last release

<ekaitz>i didn't yet, but i wanted to

<ekaitz>i'm just playing a little bit

<ekaitz>i'm not supposed to be working

<stikonas>sure, no pressure :)

<stikonas>some readign for tomorrow

<stikonas>you need time to rest too

<stikonas>especially this late

<stikonas>it's probably not yet at that point, but soon M2-Planet will be approaching mescc...

<stikonas>in terms of code that it can compile

<ekaitz>oh

<ekaitz>and I'm trying to make mes faster!

<ekaitz>my view is that mes could become more than an interpreter that runs a compiler

<ekaitz>and also, if mes is faster the compiler could be more interesting

<stikonas>well, more options is always good

<stikonas>I guess the better M2-Planet is, the easier your life in developing mes would be

<stikonas>no need to manually restrict to small subset of C

<ekaitz>stikonas: worked and mes-m2 runs perfectly

<stikonas>nice!

<stikonas>well, I'll keep PR open till tomorrow in case there are review

<stikonas>reviews

<stikonas>thanks for testing

<stikonas>I suspect obvious review comment would be to add tests...

<ekaitz>i only tested with characters

<ekaitz>but i didn't test with enums or any other thing

<ekaitz>feel free to use my switch/case as a test

<ekaitz>it's a pretty common parser for escape codes in a string

<oriansj>well we don't support the full range of escape codes in M2-Planet

<stikonas>we do support octal ones now :)

<ekaitz>i don't think mes supports all of them either

<ekaitz>but i mean the test case is a pretty common pattern to have in code, specially in compilers

<stikonas>yeah... it's that classic example of "trusting trust"

<stikonas>where you can't find the actual value in source of the compiler

<stikonas>it propagates from the earlier compiler

<ekaitz>well, tomorrow i'll test more things

<ekaitz>thanks for the help stikonas

<stikonas>sure, no problem :)

<stikonas>it wasn't hard at least

<ekaitz>;)

<matrix_bridge><gtker> Stikonas: Maybe update tests with the new constant expr things?

<matrix_bridge><Andrius Štikonas> gtker: yeah will do so in the evening

<matrix_bridge><Andrius Štikonas> gtker: we also need to submit your new M1 defines to mes repo...

<matrix_bridge><Andrius Štikonas> To https://git.savannah.gnu.org/cgit/mes.git/tree/lib/m2/x86_64/x86_64_defs.M1

<matrix_bridge><Andrius Štikonas> And I guess to x86 folder too

<matrix_bridge><gtker> stikonas: How exactly do we do that? I'm getting a 502 with that link

<matrix_bridge><gtker> Also, I would like to add oriansj suggestion regarding 2 byte values in a quick PR

<matrix_bridge><Andrius Štikonas> gtker: that link should work, I guess just server is too overloaded

<matrix_bridge><Andrius Štikonas> but submission is via email patches to bug-mes@gnu.org

<matrix_bridge><gtker> I'm not too fond of email based patches, do you mind doing it?

<matrix_bridge><gtker> I could add some tests for the new constant expressions instead if you want

<matrix_bridge><Andrius Štikonas> well, I can do both (probably today)

<matrix_bridge><Andrius Štikonas> but yeah, if you want to create some tests

<matrix_bridge><Andrius Štikonas> feel free

<matrix_bridge><Andrius Štikonas> less work for me then...

<matrix_bridge><gtker> Feel free to merge your PR, I'll create a new PR based on it with the 2 byte changes and some tests for the new constant expressions

<stikonas>ok, merged that first PR

<stikonas>gtker: I'm now looking at 101. So tat 2 byte changes is still not clear to me

<stikonas>that wouldn't work on risc-v, would it?

<stikonas>we could perhaps make $ work on risc-v too since that is unused

<stikonas>but @ is already used there for other purpose

<stikonas> https://github.com/oriansj/mescc-tools/blob/98d391202736d1b766aa50e779c61b2cac731ee0/M1-macro.c#L629

<matrix_bridge><gtker> It's based on oriansjs comment previously: "gtker: for byte based architectures the way to express signed 16bit values is @0x1234 but for unsigned 16bit values is $0x1234"

<matrix_bridge><gtker> Hmm yeah, OK, so that won't work at all

<matrix_bridge><gtker> I'll remove that commit and repush

<matrix_bridge><gtker> PR updated

<stikonas>hmm, need to think how to do it properly :(

<stikonas>but I guess need some kind of M1 change

<matrix_bridge><gtker> Yeah, either that or manually keep track in M2-Planet and switch them. It's probably best to do it in M1 though

<stikonas>cauase this 16-bit feature is still useful

<stikonas>e.g. in M2libc we have code like this: https://github.com/oriansj/M2libc/blob/5a7c12a7be39cbce113c5459d77467b829a1ecc5/uefi/uefi.c#L821

<stikonas>which was a workaround for missing initializers

<stikonas>well, here of course it's eventually using emit_load_immediate()

<matrix_bridge><gtker> Hmm, yeah

<matrix_bridge><gtker> We'll probably need M1 support. It's probably the cleanest way as well

<matrix_bridge><gtker> stikonas: Is the known_issues.org file still used for tracking or should I just create github issues for the ones that are currently there and remove it?

<stikonas>gtker: known_issues.org I guess

<stikonas>well, we do have some duplication though

<stikonas>I guess known_issues.org is more like a note to users

<matrix_bridge><gtker> The first one, "AMD64 & AArch64 int initialization wrong" I'm not even sure if that's true any more?

<matrix_bridge><gtker> Personally I looked at the github issue tracker first when I had a problem. Only realized the file was there afterwards

<stikonas>hmm, not sure what it means either. oriansj, do you know?

IRC channel logs

2025-03-14.log