~crc_

Trackers

~crc_/retroforth

Last active a month ago

~crc_/gopher-client

Last active 6 months ago

~crc_/ngata

Last active 7 months ago

#83 Unsigned Numbers & Extended Precision a month ago

on ~crc_/retroforth

REPORTED RESOLVED IMPLEMENTED

#83 Unsigned Numbers & Extended Precision a month ago

Comment by ~crc_ on ~crc_/retroforth

I have implemented but not yet documented:

unsigned:shift
unsigned:+
unsigned:-
unsigned:*
unsigned:/mod
unsigned:eq?
unsigned:-eq?
unsigned:lt?
unsigned:gt?

In Napia, this is baked into the instruction set. Under Nga, it makes use of an I/O device to enable this, but implements the overall logic in a similar manner to Napia.

Implementation of */mod is next.

#83 Unsigned Numbers & Extended Precision a month ago

2021.10 added by ~crc_ on ~crc_/retroforth

#83 Unsigned Numbers & Extended Precision a month ago

Ticket created by ~crc_ on ~crc_/retroforth

I've never implemented unsigned operations in Retro up to this point, but there are cases where they can be useful.

I am now planning to add an I/O device to support some operations on them in the near future, and to allow for better precision on some operations.

Initial functions planned:

shift/right-unsigned

Extended precision (using 64-bits intermediate):

*/mod

What other functions should this support?

#80 Multicore: Documentation: Glossary a month ago

on ~crc_/retroforth

REPORTED RESOLVED IMPLEMENTED

#71 RFC: String Performance a month ago

on ~crc_/retroforth

REPORTED RESOLVED WONT_FIX

#1 suggesion: repurpose i/o (port 0) (type 0) as the type manager a month ago

on ~crc_/retroforth

REPORTED RESOLVED BY_DESIGN

#79 Multicore: Forth Words a month ago

on ~crc_/retroforth

REPORTED RESOLVED IMPLEMENTED

#81 Multicore: Documentation: Manual a month ago

on ~crc_/retroforth

REPORTED RESOLVED IMPLEMENTED

#82 UTF8 and Strings 3 months ago

Ticket created by ~crc_ on ~crc_/retroforth

#Background

Strings in Retro currently have a few issues.

  • ASCII only (currently Retro allows for strings containing UTF8, but does not provide words for actually manipulating UTF8 characters)
  • Null terminated
  • There is a lot of overlap with the functionality provided by arrays

I will be making changes to resolve these, but it will not be a quick process. Changing the strings model will break (to various degrees) backwards compatibility, so this is not something that'll be rushed.

My current plan:

#Stage 1(a): New String Words

I will introduce s:fetch and s:store to update characters in a string. For the standard strings, this will be a thin layer over fetch and store. For the new strings, these will be a little more involved.

#Stage 1(b): Introduce UTF8 strings.

  • UTF8 strings will be arrays of character data.
  • There will be a us: (utf8 string) namespace for words operating on them.
  • A sigil for creating them will be provided.
  • Match functionality in existing string vocabulary.
  • Reuse array words internally when possible.

#Stage 2: Consolidation

This will involve updating the array words.

  • Indirection in access words (fetch, store, etc)

I will need to insert some indirection (to allow for things like us:fetch and us:store to be used when updating arrays that contain utf8 data). This will also aid in allowing for arrays of byte or halfword data.

To be continued as feedback is gathered and work progresses