HSPTV!掲示板

64ビット版ソフトを作るHSPへ、本格的に移行を初めて欲しいです！
下位互換性も大事だとは思いますが、HSPで作ったソフトを将来まで動かすことを考えた時、
そろそろ64ビットメインにした方がいいかと思います！
32ビット版アプリを作っても、はたしていつまで動くだろうか…と最近気になるようになりました。
ホビープログラマ界ではまだまだ32ビットは現役ですが
(というよりAMD64の仕様がめんどくさいので32ビットの方が楽)、
マイクロソフトのサポートや、マイクロソフトのリファレンスがもう64ビット中心になってきました。

HSP2とか3はそのまま残しといて、HSP4とかにして64ビット中心にするのはどうでしょう。
とにかくHSPもまだまだ長くつづいてほしいです。

HSP2/3 は互換性と教育目的のため、「クラシック」ブランチとして維持してください。

一部のレガシー機能を段階的に廃止することになったとしても、最新の 64 ビットコンパイラ、ランタイム、ツールを備えた HSP4（または同等のバージョン）を作成してください。

既存のプロジェクトが少なくとも移行モードでコンパイルおよび実行できるように、移行ツールまたは互換性レイヤーを提供してください。
https://geometrydash-subzero.io

私も64ビットになって欲しいですねー。
32ビットだとメモリ制限とか、現況と合わなさすぎな部分があるので。

過去のプラグイン類が使えなくなっちゃうのはあるので、互換性を重視するHSPにとっては難しいのかもだけれど。
出遅れすぎって言っても怒られない時代まで行っちゃってると思うのです。

hsp3_64仕様だと、intとポインターが32bitから、intが32bitでポインターが64bitになるので
インタプリタ側だけじゃなくてスクリプト側も対応が必要そうです。

intとは別にint64とfloat型追加して、dupptrやpeekやuselibやcfuncではint64を使ってというのは試作してみていて
C/C++を書きなれてる身としては普通なんですがスクリプト言語的なシンプルさは遠のきますね。
https://github.com/zakki/OpenHSP-fork/commits/ffi-types/

ポインタの扱いが変わるので全体的に仕組みの書き換えが必要になる部分なので
結構大変だと思われますが、私もそろそろちゃんと対応して頂けたほうがいいとは思ってます。
LongLongな変数も標準では無いんで、外部APIの64bit値がそのまま受け取れない問題もあります。

ですが、32bitとの互換性も維持してほしいと思っています。
HSP4では恐らくここに対応してくると予想しているのですが、
ネイティブコードに対応の予定があると聞いたので、
コンパイラで対応するんじゃないかと思っていたりします。

ただ、手軽にrunさせるためのインタープリタも捨てがたいですよね。

最新の説明書(スクリプトエディタでF1)の「HSP3 概要」をご覧ください。
以下引用します。

> HSP3.8
> HSP3.7で導入できなかった機能や不具合については、引き続きアップデート版を更新していきます。今後導入する予定として検討されている機能は、以下の通りです。(この順番で行われるということではありません。)

> HSP4
> HSP2が登場したのが1997年、HSP3はその8年後になりますが、時代の変化とともに次の世代に繋げることができればと考えています。 プログラミングに求められている状況も変わってきています。HSPの手軽さを継承した上で、ある程度互換性をカットして使いやすいものを、この先ロードマップとして発表していければと思っています。
> 現在検討しているのは、完全なUTF-8、64bit対応、コード自動解析と学習機能、VMの刷新(llvmなど)、ネイティブコンパイル(JIT)などになります。

No.104001とかほかスレッドのNO.104003は生成AIのスパムですね…
それをきっかけで盛り上がっているようなので複雑ですが

ほんとだwww リンクは気にしてませんでした。